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SUMMARY OF WORKSHOP CONCLUSIONS 


The Office of Space and Terrestrial Applications (OSTA) /Applications Data 
Service (ADS) Data Systems Standards Workshop was held at the Goddard Space 
Flight Center in Greenbelt, Maryland on May 27-29, 1981. The purpose of 
the workshop was to identify standards needed to interconnect ADS pilots 
for data sharing; to assess current pilot methodologies; and to make 
recommendations for future work. The theme of the four workshop panels was 
"Standards Needed to Interconnect ADS Pilots for Data Sharing." Their 
topics were: Catalogues, Directories, and Dictionaries; User Interfaces; 

The Use of ISO Open Systems Interconnection - Basic Reference Model; and 
Data Formats and Descriptions. 

Panel A identified a preliminary set of requirements for guidelines and 
standards for catalogues, directories, and dictionaries, which are found 
in Section 11 of this document. The panel found it necessary to identify 
and define a structure for repository of information about data and defined 
the following terms: 

DIRECTORY Definition: High-level description of data sets available 

to all ADS users. The directory is accessed by means of a standard 
user interface. 

LOCAL CATALOG Definition: Detailed description of data sets. The 

local catalogs are maintained by the organization that is also re- 
sponsible for maintaining those data sets. 

The structure below the directory may contain intermediate levels of 
directories which are both local- and network- implementation dependent. 
Standards in the near term need only to be specified for the DIRECTORY. 

Panel A recommended: 

(1) A continuing Directory/Catalog Standards Working Group to advise 
the ADS Standards Program on Directory/Catalog matters and to provide 
advisory review of contractor products related to Directories and Catalogs 
with membership from each of the pilots and the OSTA/ ADS Standards Program. 

(2) A Directory /Catalog Implementation Working Group to provide: 
assessment of current ADS pilot methodologies, studies for alternative 
implementation methods of the directory, detailed design of the directory, 
determination of software functional requirements, design of interface 
between directory and local catalogs of pilots , and consideration of 
library and information science methodologies for its relevance. 

(3) Policy be set concerning the release of information about data 
to ADS. 

(4) Adoption or modifications of the WALLOPS definitions for data 
levels . 

(5) Continuing discipline user working groups be established. 
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Panel B viewed the "user" as a discipline scientist at a terminal trying to 
get data out of the network. It was assumed that the user is primarily 
associated with one of the local systems, such as VAS or the Ocean Pilot. 

In the short and intermediate term, users will connect to their "home" 
system and obtain network services through it. Network services will be 
visible to the user as separate from local system services. The panel 
considered the requirements for standards and guidelines in the areas of 
User Interfaces; their report is in Section 12. 

Panel B recognized a need for a continuing oversight body for maintaining 
and monitoring standards and guidelines. The panel recommended that there 
be a continued panel existence more or less as a design review committee 
to Influence and monitor TAE, RSS, and allied efforts from the point of 
view of user interface, with members represented from pilots, ADS Standards 
Office, NASA Headquarters, other TAE users, and TAE developers. The panel 
also recommended that a liaison be maintained with CODASYL and ANSI to 
monitor work in command languages. 

In order to determine the relevance of the OSI Reference Model for address- 
ing ADS requirements. Panel C considered a scenario representing a broad 
class of capabilities which were considered required to interconnect the 
pilots for data sharing. The interconnection protocols needed to support 
this scenario were then identified, and these protocols were then classified 
in terms of standard layers within the OSI Reference Model. Panel C's 
report is in Section 13. 

Panel C considered three basic approaches which could be considered for 
an integrated ADS pilot network system and the advantages and disadvantages 
associated with each. The approach favored by the panel, to adopt existing 
and emerging national and international telecommunication standards to the 
greatest possible degree, involves the tentative acceptance of protocols 
which are so new and unproven that they exist only as draft standards. 

It is anticipated that, after an extensive review process, these protocols 
will become FIPS and be required for future telecommunications support on 
U.S. Government systems. 

Panel C recommended that a working group be established to continue to 
investigate identified issues and to track the progress toward a successful 
interconnection of ADS pilots. Some specific topics for the Working Group 
investigations recommended are: 

(1) Review currently identified requirements versus other panels for 
consistency and completeness. 

(2) Develop functional specification of input parameters for each 
application to be supported (input to layer 7). 

(3) Develop design specifications of output strings/packets/message 
blocks for each application to be supported (output "from 6 to 5") . 

(4) Evaluate existing layer 4 and 5 protocols, including the NBS 
proposed standard, and recommend selection for pilot system and future 
ADS use. 
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(5) Perform a requirements analysis for the ADS at the combined 
layers 1-3. 

(6) Specify core requirements expected for each protocol layer for 
pilots and future ADS use. 

It was the consensus of Panel D that data exchange standards should be 
developed to be of general future utility, though the near-term activity 
should be constrained to focus on the problems of interconnecting the 
ADS pilots. The panel report is in Section 14. 

Panel D recommended; 

(1) ADS should establish a standard vocabulary of terms, units, 
descriptions, and definitions. 

(2) ADS should provide a machine-readable standard mechanism, 
which is medium and machine independent, for describing data content, 
structures, numeric representations, and character codes. 

(3) ADS should establish a set of preferred numeric representa- 
tions, a preferred character code, preferred units, and preferred de- 
scriptions. 

(4) ADS should establish a permanent, dedicated team to pursue this 
effort further and recommended the following near-term outline. 

a. The permanent team should begin by analyzing the data formats, 
codes and representations used in exisitng pilots. 

b. The team should analyze existing and proposed data interchange 
standards. 

c. The team should adopt or create Strawman standards for review 
by data base administrators for each pilot and associated NASA 
data base. 

d. The team should establish an ADS data standards administration 
function to approve, disseminate, maintain and provide 
visibility for these standards. 

e. The team should provide top-level coordination for the 
development of catalogs, in order to provide to the catalog 
designers the mechanisms for describing data sets and to 
evaluate the adequacy of the catalog structures to enable 
users to access and select data. 

Before adjourning, the workshop unanimously recommended the development of 
a standard for data product preparation to ensure quality data sets. The 
recommendation prepared by Richard desJardins, as given in Table 15-1, was 
adopted. The workshop emphasized that there is a lot of work to be done 
in the standards area. 
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WORKSHOP SUMMARY 


1 . INTRODUCTION 

The Office of Space and Terrestrial Applications (OSTA)/Applications Data 
Service (ADS) Data Systems Standards Workshop was held at the Goddard Space 
Flight Center in Greenbelt, Maryland on May 27-29, 1981. The purpose of 
the workshop was to identify standards needed to interconnect ADS pilots 
for data sharing, to assess current pilot methodologies, and to make 
recommendations for future work. The theme of the four workshop panels was 
"Standards Needed to Interconnect ADS Pilots for Data Sharing." Their 
topics were; Catalogues, Directories, and Dictionaries; User Interfaces; 
The Use of ISO Open Systems Interconnection - Basic Reference Model; and 
Data Formats and Descriptions. 

Dr. Paul B. Schneck opened the workshop hy welcoming the participants to 
the Goddard Space Plight Center. He set the stage for the workshop by 
stressing the importance of ADS in NASA's future. 

Barbara Walton said that the near-term goal for OSTA/ADS is to provide the 
capability for interconnecting the pilots for data sharing. There are 
three major pilots within ADS at the present time; Oceans Pilot at JPL, 
Earth Resources Pilot at Johnson Space Center, and the Atmospheres Pilot at 
the Goddard Space Plight Center. The plan is to form a network 
(interconnection) to share data between disciplines and users. 

2. OSTA DATA SYSTEMS PLANNING WORKSHOP 


Dick desJardins presented the OSTA Data Systems Planning Workshop recom- 
mendations. The purpose of the OSTA Data Systems Planning Workshop, held 
at Wallops Island on October 9-12, 1979, was to recommend a data system 
concept and requirements to OSTA. A concept includes "a means for 
identifying the work that has to be done, identifying the relationships 
between the people who have to do the work, and some kind of a 
modularization scheme for the system." The purpose of flying spacecraft is 
not to fly hardware but to build data sets from remote sensing. Panels 
were composed of people who had problems and people who had solutions. 
Disciplines represented were agriculture; land resources; hydrology; 
geology and geodynamics; atmosphere; and oceans. There were also panels on 
overall data systems; onboard data systems; data acquisition, distribution 
and operations; information extraction and processing, and user facilities; 
and data base storage and management. 

The integrated discipline requirements identified by the OSTA Workshop 
participants are; 

(l ) Quality data sets are needed which are clean, useful, and 
processable. The project or discipline must produce parameter data sets 
(of physical phenomena) which meet the program objectives. OSTA needs a 
systematic treatment of problems with present data. Scientific data 
management personnel should be responsible for the quality of the product, 
the planning of the product, and seeing that users get the data that they 
want. The pedigree of the data is important. Sun angle, calibration, 
algorithms for parameterizations, etc. are needed. 
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( 2 ) OSTA needs a single integrated data catalog or "Master Directory." 
ADS should be one means to access the catalog to help the researcher find 
out how to get the data and avoid wasting time doing it. 

(3) OSTA needs continuity of data formats. A single format is not 
necessary; there should be a few, fairly standardized formats. Data levels 
should be defined. 

(4) OSTA needs to reference its data to a standard geographic and time 
basis. Every piece of data should be marked with latitude, longitude, 
altitude and Universal Time. 

(5) OSTA needs data delivery. Usually there is no need for immediate 

access to data. What is needed is easy accessibility ; ability to get data 
by means of mail or electronic transmission. Each project has a 
"freshness" requirement. , 

( 6 ) OSTA needs appropriate data archives to provide a place to store 
data. There is a need for uniformity in policy for keeping, indexing, or 
managing that data. A policy of active archives is required. Scientific 
data management should provide accessible data. 

(7) Cooperation with user agencies is necessary for OSTA. USGS and 
NOAA, as examples, have similar needs and problems, and NASA needs to be in 
harmony with operational data from other agencies. 

Figure 1 shows the overall OSTA Data System Concept. Working storage is 
provided for researchers. At the level shown in the figure, ADS tells us 
what standards are necessary for making data available. ADS would provide 
consultation and a Master Directory. The concept should be cost- 
accountable; it should produce Level 1 A data sets. It could be phased over 
to commercial service. It was never a concept for electronic data 
dissemination. The data have to cost-effectively satisfy multiple 
objectives. The policy recommended was to store all the information that a 
user needs along with the raw measurement: sensor measurement data, sensor 

ancillary data, calibration with instrument, etc. The data must be stored 
in a form such that original data may be recovered. To do all this, OSTA 
must implement research in data input and data dissemination to meet its 
needs. 

3. THE ROLE OF THE ADS PILOTS 


J. Patrick Gary addressed the role of pilots. This workshop is effectively 
a working group for standards. We now need more detailed specification of 
hardware interfaces, communications protocols, data exchange services, etc. 
This workshop should be viewed as a working group to define areas within 
the data systems concept where standards are required. 

The overall goals of the ADS Program are to provide OSTA data users with 
timely and effective access to needed data and information within and 
outside of NASA and to provide standards/guidelines for future OSTA 
programs to evolve data systems and data management towards compatibility 
where appropriate. OSTA data users require timely and effective access to 
needed data in a uniform way. We must not over standardize. The pilots are 




Figure 1. OSTA Data System Concept 















planned to evaluate the utilization of current techniques and technologies 
in the use and exchange of data and to facilitate access to data (DBMS, 

Data Management, etc.)* 

The pilots are to provide demonstrations of the use of advanced 
technologies, provide a test-bed environment for data handling technique 
evaluation, evolve ADS requirements and capabilities (long-term goal), and 
document validated methodologies as standards and guidelines for OSTA data 
system use. These objectives are carried out in order to apply technology 
in a service capacity in support of the research programs of the 
application disciplines. The three pilots, when they interconnect, have a 
chance to "test bed" distributed processing and data sharing concepts 
needed to meet ADS near-term requirements. In time, they will come to test 
concepts applicable to much of NASA. To interconnect the ADS pilots for 
data sharing, two key functions are needed: l) Users must know what data 
are available, and 2) data must be exchangeable among facilities. 

The relationship of pilot program activities to the standards development 
process is shown in Figure 2. Inputs and evaluative criticism from the 
users, pilots, and Headquarters are required in the standards development 
process. The process starts with requirements for standards, but we must 
not overstandardize. Standards are useful to describe: 1) how to describe 

2) how to build; and 3) how to apply. Should ADS find that the current 
standards or methodologies are not adequate or applicable to its needs, the 
pilots can test new methodologies or proposed standards and develop them. 
The establishment and dissemination of standards is a high level management 
function. A result of this standards development process feeding back to 
the pilots will be standards useful to the design and the specification of 
new systems. 

Figure 3 shows the overall ADS development approach with its gradual 
expansion of capabilities. The process is iterative; feedback to and from 
working groups, such as a standards working group, is essential for 
progress. 

4. THE OSTA/ADS standards DEVELOPMENT PROCESS 

Barbara Walton stated that the goals of the OSTA/ADS Data Systems Standards 
Program Were formulated in response to the need for standards for sharing 
data. The goal of the program is to provide effective data exchange and 
data system interface, standards and guidelines for OSTA programs. Its 
objectives are to: 1) identify and recommend use of data system standards 

and guidelines applicable to OSTA/ADS; 2) develop and maintain OSTA/ADS- 
unique data system standards and guidelines; and 3) coordinate with OSTA 
programs, ADS pilots and pertinent standards activities within and outside 
NASA. Applicable standards of the National Bureau of Standards and other 
existing standards can be used, but ADS and OSTA have unique problems. 

NASA has already dealt with some of the unique problems, such as the 
Landsat images COT (Computer-Compatible Tape) standards; however, there are 
other development efforts that NASA will be dealing with in the near 
future. 


S-4 



S-5 


RELATIONSHIP OF OSTA/ADS PILOTS TO THE STAMDARDS DEVELOPMENT PROCESS 
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In 1980, a phased approach was developed for the program. FY81 Phase 1 
projects focused on ADS and included a standards survey, standards 
requirements study, pilot methodology survey, and evaluation process and 
criteria. "Candidate" standards will he produced and the results are due 
to be published this year. This program builds on the results of the OSTA 
Workshop and the feasibility study reported on by Dick desJardins. This 
workshop will review, modify, and evaluate these processes so that those 
standards which might be applicable to ADS -may become candidate standards 
for ADS. 

The following remains to be done: ADS planning, interim standards, a 

concept for implementation of a "Core ADS," definition of OSTA data systems 
policy, and full-capability ADS definition. Phase 2, in FY82 and FY83, 
expands the focus to OSTA data systems and "Core ADS." Phase 3» focuses on 
the future goal of a "full-capability ADS." Once a full set of standards 
has been developed, a systematic review and periodic update will be needed. 
Standards will evolve as needs evolve. 

5. THE CURRENT MITRE EFFORT 

Terry Kuch and Rick Sakamoto presented an introduction to MITRE 's support 
of the OSTA/ADS standards and guidelines program. The three MITRE 
presentations at the workshop concentrated on functions needed for 
near-term data sharing among ADS member systems. Sharing of computational 
facilities and software were considered to be longer-term ADS goals. 

MITRE adopted a logical view of ADS as a distributed system, which 
distinguishes among seven components of such a system: 1 ) providers of 

data; 2) providers of applications software; 3) providers of computational 
facilities; 4) users of data, software, or computational facilities; 

5) administrative services; 6) technical services such as documentation and 
location support for data, software, and computational facilities; and 
7) support for data communication. Based on this logical view, MITRE 
developed a hierarchical classification scheme of ADS features at a level 
of detail (70 nodes) appropriate to the level of detail addressed by most 
Federal, national, and international information processing standards. 

This feature classification provided the framework for a preliminary 
assessment of the applicability of Federal, national, and international 
standards to ADS. These standards were gathered, screened, documented 
briefly, and reported in NASA contractor report CR 166675. 

Two key efforts were initiated to survey methodologies of the three ADS 
pilots and to identify the requirements for standards of ADS members based 
on a survey of the pilots and on representative potential future members. 
Preliminary results of the requirements survey were used in the development 
of a process and criteria for the evaluation of potential Standards for 
OSTA/ADS. An overview of the evaluation process was presented and examples 
of standards passed through the process. 

Paul Clemens presented the results of a survey of ADS member requirements 
for standards and guidelines. This survey was carried out in four steps: 

1 ) identify a representative number of planned and prospective ADS members 
from ADS pilots, key OSTA programs, and other sources; 2) survey the 
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identified members; 3) define and document members' needs for ADS system 
capabilities and services; and 4) derive ADS standards and guidelines 
requirements from this survey of members' needs. 

The survey included the interpretation and analysis of functional 
requirements from three sources: 1) earlier OSTA/ADS data system studies, 

2) current ADS pilot activities, studies, and documentation, and 3) 
prospective ADS members' activities and documentation. Requirements in 
each case were then reviewed and modified as needed to reflect the overall 
scope of ADS. 

The resultant requirements were then tabulated and mapped into the ADS 
feature classification. The findings were analyzed for commonality of 
purpose and function and, from this analysis, overall standards 
requirements determined. 

Paul Giragosian presented the results of a survey of the methodologies 
employed by the ADS pilot programs (Atmospheres, Oceanic, Earth Resources). 
At various stages in their development, the ADS pilots have implemented or 
planned to adopt certain practices, procedures, standards, or conventions. 
The collection of these practices as applied toward a specific development 
function or operational objective constitutes the notion of a 
methodology." The primary objective of the survey was to provide an 
information base for the evaluation of these methods and their 
applicability to the future development of ADS standards and guidelines. 

6. PANEL ACTIVITIES 


Barbara Walton presented the following panel instructions: 1 ) critique the 

MITRE representation of pilot methodologies for accuracy and completeness; 
2) identify the requirements for standards and guidelines needed in your 
panel's area to interconnect the ADS pilots for data sharing; 3) make a 
preliminary assessment of the adequacy of currently identified pilot 
methodologies and external standards in meeting these requirements; 4) 
identify any other methodologies you are aware of which may contribute to 
the solution to your panel's aspect of the problem; 5) make recommendations 
for future work, providing descriptions and estimate of effort where 
possible; and 6) provide the panel's consensus on the need for a continuing 
working group in this area and suggest membership thereof. 

She then introduced the following panel topics and assignments: 

Standards Heeded to Interconnect ADS Pilots for Data Sharing 

Panel A - Catalogues, Directories, and Dictionaries 
Chairman: Jose Urena, JPL 

Panel B - User Interfaces 
Chairman: Jim Brown, JPL 

Panel C - Use of ISO Open Systems Interconnection - Basic Reference Model 
Chairman: Ed Greene, GSFC 
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Panel D - Data Formats and Descriptions 
Chairman: Ed Greenberg, JPL 

The panels convened briefly, then broke for dinner. 

James Burrows, Director of the Institute for Computer Science and 
Technology of the National Bureau of Standards, was the dinner speaker on 
the first day of the workshop. He discussed the NBS Data Systems Standards 
Program and emphasized the communications protocol development program. 

The panels continued their work on the following days with presentations by 
the panel chairmen on the last day of the workshop. The full text of the 
panel reports is contained in Sections 11 through 14 of the proceedings. 

7. PANEL A: STANDARDS HEEDED TO INTERCONNECT ADS PILOTS FOR DATA SHARING 

FOR CATALOGUES, DIRECTORIES, AND DICTIONARIES ^ 

Panel A identified a preliminary set of requirements for guidelines and 
standards. 

(l) The panel found it necessary to identify and define a top-level 
repository of information about data in order to consider standards 
requirements. The term assigned to this "highest" level repository is 
"DIRECTORY." 

DIRECTORY Definition: High-level description of data sets 

available to all ADS users. The directory is accessed by means 
of a standard user interface. 

The detailed information about data resides in the "lowest" level 
repository. The term "LOCAL CATALOG" was assigned to it: 

LOCAL CATALOG Definition: Detailed description of data 

sets. The local catalogs are maintained by the organization 
that is also responsible for maintaining those data sets. 

The structure below the directory may contain intermediate levels of 
directories which are both local- and network- implementation dependent. 

This potential requirement was not addressed by the panel. 

The above definitions identify a structure with at least two levels. 
Standards in the near-term need only to be specified for the top level 
(DIRECTORY). 

The ADS Directory/ Catalog architectural model is depicted in Figure 4. The 
user accesses the information in the directory by means of a standard user 
interface, and logical links connect the directory with the local catalogs 
or with the intermediate level directories. The dashed lines show possible 
future logical links between the user and the local catalogs, intermediate 
directories, and data sets, that would require new standard interfaces. 
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Figure 4. ADS Directory /Catalog Architecture Model 
















































(2) A set of requirements for standards that were identified for the 
directory by Panel A is listed in the panel report (Section 11.2.2). 

( 5 ) Definitions and conventions for terminology of directory 
attributes are necessary. 

( 4 ) The panel identified a set of guidelines for the local catalog 
which are given in Section 11.2.4. 

( 5 ) A Directory User's Guide is required. 

The panel recommended: 

( 1 ) A Continuing Directory/Catalog Standards Working Group 

a. Functions of the working group would be to advise the ADS 
Standards Program on Directory/ Catalog matters and to provide 
advisory review of contractor products related to Directories 
and Catalogs. 

b. Membership should include at least one representative from 
each one of the pilots and the OSTA/ADS Standards Program. 

c. The group should consider of the need for a standard user 
interface to local catalogs and intermediate directories and 
investigate methods for incorporating terminology definitions 
accepted by recognized discipline user bodies. 

( 2 ) A Directory/Catalog Implementation Working Group to provide: a) 

assessment of current ADS pilot methodologies; b) studies for alternative 
implementation methods of the directory and selection of one; c) detailed 
design of the directory; d) determination of software functional 
requirements; e) design of interface between directory and local catalogs 
of pilots; and f) consideration of library and information science 
methodologies for its relevance. The directory could allow structured data 
retrieval and retrieval of unstructured indexed textual information. 

( 3 ) Further Recommendations 


a. Policy be set concerning the release of information about data 
to ADS. 

b. Adoption or modifications of the WALLOPS definitions for data 
levels (under area of work of Panel D on Data Formats and 
Descriptions) . 

c. There is a need for continuing discipline user working groups. 

d. Study alternatives to "in-person" meetings. 
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8. PANEL B; STANDARDS NEEDED TO INTERCONNECT ADS PILOTS FOR DATA SHARING 
FOR USER INTERFACES 


Panel B viewed the "user" as a discipline scientist at a terminal trying to 
get data out of the network. It was assumed that the user is primarily 
associated with one of the local systems, such as VAS or the Ocean Pilot. 

The panel discussed how the user views the network. Figure 5 shows some 
possibilities of the user's concept of the network services. Illustration 

(a) shows the user terminal connected to each local system with ADS 
invisible as a networking function. After discussing this arrangement, the 
panel decided that it was probably not realistic; the user would probably 
not view the system that way. Representation (c) of the system is more in 
line with the long-term ADS picture. The users dial into a system called 
ADS with its data system and information extraction services. However, in 
the short term with the three pilots that we now have, that view is not 
realistic. The resulting user view of the network systems is shown in view 

(b) . The user is aware of the ADS network added on to the local system. 
Part of the user interface will be influenced by the network and part will 
not. This view does take into account the actual network as it is likely 
to exist with the three pilots. 

In the .short and intermediate term, users will connect to their "home" 
system and obtain network services through it. Network services will be 
visible to the user as separate from local system services. The interface 
may have to be different, except where TAE or a similar "transportable 
executive" is used for both. 

The panel recognized a need for a continuing oversight body for maintaining 
and monitoring standards and guidelines. They considered the requirement 
for standards and guidelines in the following areas: 

(1 ) Dial-up Procedures . Users are connected to each local system and 
know that each one of these local systems can connect in some way with any 
other independent of location. With the exception of such things as 
retrieval time and cost, it would not be apparent to the user if the 
connection were by local or long-haul network. Since users will connect to 
local systems, no standard or guideline is needed. 

(2) Terminals . A guideline or standard based on what is needed to 
correctly support a Menu System (processor) in a user-friendly way is 
required. This implies a minimum of 1200 baud "dumb" CRT; 300 baud 
hardcopy is marginally acceptable. 

(3) Common Capabilities . The panel developed a model of the user's 
view of the catalogs and directories to use as a basis for a standard user 
interface. This model shows the local catalog(s) as transparent to the 
user. The user would deal with the high-level directory, standardized over 
the network. The linkage between the directory and the actual data set 
would be invisible. If the users have to see a local catalog or directory, 
that interface could not be standardized. ADS should seek to standardize 
the user's view of the interface to a high-level directory. 
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O USER TERMINAL 


O LOCAL SYSTEM OR 
LOCAL NETWORK 


Figure 5. User View of Network Services 



The panel prioritized the functional requirements for the pilot network for 
which standard user interfaces would be needed. These requirements are 
grouped in Table 1 based, not necessarily on functional importance, but on 
the need for standard user interface. Clarification is needed for 
functional requirements shown to accurately reflect the directory/ catalog • 
concept and criteria established by Panel A. This is an item for future 
work. 


The panel anticipates that the user will want sample data sets — the larger 
the data set, the greater the need for a variety of different samples. Tho 
user may want to look at smaller data sets quickly prior to operating on 
larger data sets. (This is a strong requirement in the Oceans Pilot.) The 
value of this function depends on the typical size of the data set vrith 
which one is dealing. The user should be aware that sample data sets exist 
and should be aware of how to get them even if the directory-pointing 
mechanism is transparent. This requirement is shown in Group 3 to indicate 
that it is a longer term effort. 

(4) Language Interfaces . It is hoped that TAE and RSS will develop 
into the defacto standard for the three pilots, with possible modificationis 
based on current pilot methodologies and external standards. 


(5) User Consultant . There should be a human user consultant, 
available to be used for human- to-hioman assistance. Guidelines are needed 


for a user consultant. The scope of the guidelines includes who, how m 
organization (local system, local network, ADS network), functions, and 
expertise. 


any, 


The panel recommended that there be a continued panel existence more on 
less as a design review committee to influence and monitor TAE, RSS, and 
allied efforts from the point of view of user interface, with members 
represented from pilots, ADS Standards Office, NASA Headquarters, other TAE 
users, and TAE developers. 

There is a need to clarify TAE maintenance and control policy , 
organization, and authority of the review committee. The charter of the 
TAE/RSS review committee should be to test and evaluate the software to be 
used; to recommend changes to be done; to review documentation. 

The panel recommended that liaison be maintained with CODASYL'and ANSI to 
monitor work in command languages. The panel also recommended that there 
be a study to understand user interface procedures of technology transfer 
organizations, e.g. , Eastern Regional Remote Sensing Applications Center 
(ERRSAC), etc. for both human training and computer methodologies. 

9. PANEL C: STANDARDS NEEDED FOR THE USE OF ISO OPEN SYSTEMS 
interconnection - BASIC REFERENCE MODEL 

All three pilot programs were represented on Panel C. Given the diverse 
background of the participants and the limited time available for 
discussion, the panel was unable to explore the many detailed interface 
considerations needed to thoroughly analyze the relevance of the OSI 
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TABLE 1 

PILOT NETWORK FUNCTIONAL REQUIREMENTS 
GROUP 1 - MANDATORY 


• COPY "PILE" 

• DISPLAY DIRECTORY CONTENTS 

• DIRECTORY ATTRIBUTE SEARCH 

• CREATE DIRECTORY ENTRY 

• MODIFY DIRECTORY ENTRY (SOME ATTRIBUTES PROTECTED) 

• DELETE DIRECTORY ENTRY (AND CORRESPONDING DATA SET) 

• HELP 

• DISPLAY STATUS OF ANY OF THE ABOVE PROCESSES (IF APPRO- 
PRIATE) 

PRIORITY GROUP 2 

• DISPLAY NETWORK STATUS/STATISTICS 

• SEND MESSAGE 

- TO LOGGED-ON USER 

- TO MAILBOX . 

PRIORITY GROUP 3 

• PROVIDE SAMPLE DATA SETS 

- PRE-CANNED 

- FIRST N POINTS, RECORDS,... 

C- STAPLED, AVERAGED, . . . ] 

• PROVIDE ESTIMATES OF "COST" BEFORE EXECUTING A NETWORK 
OPERATION 

- DATA SET SIZE 

- ELAPSED TIME 

- COST (IF USED) 

• BROWSE 

• SEND MESSAGE TO BILLBOARD 

GROUP 4 * 

• NETWORK LOG ON/OFF 

- TRANSPARENT TO USER 

• establish/remove/modify USER AUTHORIZATION 

- NOT AVAILABLE TO USER 

• RUN/CANCEL explicit PROCESS 

- FUNCTION NOT NEEDED IN SHORT TERM 

• SEND BROADCAST MESSAGE 

- NOT AVAILABLE TO USER 

• DIAL-UP, LOCAL SYSTEM LOG ON/OFF 

- CANNOT STANDARDIZE 


*Functions may be required, but user interface standards/ 
guidelines are not required. 
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Reference Model to the ADS. Nevertheless, the panel concentrated its 
efforts hy performing a top-level mapping between the conjectured ADS 
requirements and the identified layers within the OSI Reference Model. A 
number of issues of a more detailed nature were identified for further , 
study. 

The OSI Reference Model represents a conceptual architecture for 
telecommunication interconnections which consists of a hierarchical 
structure composed of seven layers. The principal functions performed or 
services rendered by each layer is shown in Table 2. At each level, there 
is an illusion of a direct peer-to-peer protocol connecting the two 
systems. However, in reality, the actual control and data communication is 
between adjacent layers. The H-th layer protocol performs identifiable 
services to the (N+1 )-st layer and, in turn, requests services from the 
(N-1 )-st layer. If the two systems are distinct, then the actual signal 
communication is performed at the Physical Layer (layer 1). The interface 
to the applications process is at the Applications Layer (layer 7). 

At the lowest three layers, there are existing protocols that conform 
substantially with the OSI Reference Model. Beyond layer 3, there are no 
nonproprietary general-purpose protocols which have been extensively 
tested; however, this is a field of active research within both the U.S. 
and European communities. Draft standards have been issued by the National 
Bureau of Standards (NBS) for both a Transport Layer and a Session Layer 
protocol. It is anticipated that these draft standards may emerge as 
mandatory Federal Information Processing Standards (PIPS) (for U.S. 
government systems) after these protocols have been extensively reviewed 
and tested. Both IBM and Digital Equipment Corporation have 
telecommunications software (SNA and DECNET, respectively) that provides 
services at all layers for networking among compatible-computer ‘systems. 

Table 2 

OSI Reference Model Layers 


Layer 

Name 

Description 

1 

Physical 

Physical signal interconnect from 
point-to-point 

2: • 

Link Control i 

Data interconnect from 
point-to-point 

3 

Network 

End-to-End data interconnect 
(Source DTE to Destination DTE) 

4 

Transport 

Host-to-Host data transfer 

5 

Session 

Dialogue synchronization between 
hosts 

6 

Presentation 

Data conversion services 

7 

Application 

Interface to application processes 
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In order to determine the relevance of the OSI Reference Model for 
addressing ADS requirements, Panel C considered a scenario, described in 
Section 13*3, representing a broad class of capabilities which were 
considered required to interconnect the pilots for data sharing. The 
interconnection protocols needed to support this scenario were then 
identified, and these protocols were then classified in terms of standard 
layers within .the OSI Reference Model. 

The scenario consisted of a series of steps in which an investigator 
utilizes a terminal to perform a search of a nonlocal data base, initiates 
the execution of a process resident on a remote processor using the 
selected data set as input data, copies the generated data set to a 
different procersor where it is added to the data base, the corresponding 
directories and catalogs are updated, and an electronic mail notification 
of the new data set is given to selected colleagues. 

To support this scenario, the protocols listed in Table 3 are required. 
Items 1, 2, 5, and 9 are essential layer 5 functions, and the remaining 
items are combined layer 6 and layer 7 functions. Since nonlocal 
intercomputer communication is required by this scenario, layer 1, 2, 3, 
and 4 protocols are required to support the higher layer protocols. 

Other capabilities were discussed as appropriate for long-term ADS 
consideration, but beyond the scope of that needed to interconnect ADS 
pilots for data sharing, included distributed data bases, multiprocessor 
application processing, and generalized word processing (interoperability 
among equipment from diverse manufacturers). Additional layer 5, 6, and 7 
protocol services would be needed to support these functions. 

Table 3 

Protocols Required to Support Scenario 

1 . Terminal support 
— Local 

— Dial-in through network* 

2. Automatic login/accounting to applications manager 

3. Catalog manager. command/ response interaction, data base inquiry 
and response (command language, data descriptors) 

4. File transfer 

5. Applications executive interaction (suspend/ resume, etc.) 

6. Privacy/security services 

7. Message to operator/mailboxes 

8. JSC word processor access* 

9. Automatic log off 


*Additional near-term capability not directly derived from scenario 
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The Pilot Atmospheres Data System (PADS) at the Goddard Space Flight Center 
and the Earth Resources Pilot System (ERPS) at the Lyndon B. Johnson Space 
Center have developed and adapted telecommunications software to service 
the needs of their individual pilot demonstrations. The computer system 
for the Oceans Pilot System (OPS) at the Jet Propulsion Laboratory will be 
delivered this summer and is expected to utilize the DECNET software for 
intrapilot networking. Figure 6 shows the initial telecommunications 
software that is being implemented for each pilot. The classification of 
the software into OSI Reference Model layers is only approximate. 

The panel considered three basic approaches which could be considered for 
an integrated ADS pilot network system and the advantages and disadvantages 
associated with each. The approach favored by the panel, to adopt existing 
and emerging national and international telecommunication standards to the 
greatest possible degree, involves the tentative acceptance of protocols 
which are so new and unproven that they exist only as draft standards. The 
NBS has issued specifications of a layer 4 (Transport) and layer 5 
(Session) protocol which appear to be the leading contenders for standard 
protocols at these levels. It is anticipated that, after an extensive 
review process, these protocols will become FIPS and be required for future 
telecommunications support on U.S. Government systems. The proposed draft 
layer 4 protocol is intended to provide the proper interface to the major 
existing layer 3 protocol such as X.25 and X.21. 

Above layer 5, the processing functions become so diverse that there 
appears little hope for the development of a single standard protocol at 
layer 6 or layer 7 in the near future. Instead, it is likely that a series 
of standard modules will be developed which perform certain well-defined 
functions at layers 6/7 and which interface to the standard layer 5 
protocol. One such module, the NBS File Transfer Protocol, is scheduled to 
be released in draft form in early 1982. Other standard modules will 
undoubtedly be developed but probably not on a timeframe that will benefit 
the ADS. 

The panel did not have the time to assess the adequacy of the NBS draft 
protocols at layers 4 and 5. Nevertheless, the consensus of the panel was 
that this approach deserves cautious support. ' While this approach is 
likely to be the most frustrating and difficult on a short-term basis, it 
is the only approach which offers a potentially viable solution for the 
effective networking among non-homogeneous systems. , Figure 7 illustrates 
some of the protocols that are needed for the candidate ADS configuration 
and their relationship to the OSI Reference Model. 

Panel C recommended that a working group be established to continue to 
investigate these issues and to track the progress toward a successful 
interconnection of ADS pilots. Listed below are some specific topics for 
the Working Group investigations: 

(l ) Review currently identified requirements versus other panels for 
consistency and completeness. 

Panel C identified the need for protocols to support the functions 
identified in Table 3. These requirements need be compared with the 
requirements identified by other panels for consistency and completeness. 
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NEAR TERM CONFIGURATION 
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Figure 6. Near-Term Configuration 
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INTEGRATED CONFIGURATION CANDIDATE 
(TWO OR MORE YEARS IN FUTURE) 


NBS 
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FILE 

ACCESS 

TRANSFER 

PROTOCOL 

PROTOCOL 

(FUTURE) 





OR OTHER 
DEDICATED 
LINE 
SERVICE 


OTHER 
(LOCAL AREA 
NET. SATELLITE 
TDMA, ETC.) 
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The intent is to direct • attention to provide or plan protocols to meet any 
extra requirements. 

(2) Develop functional specification of input parameters for each 
application to he supported (input to layer 7). 

After the requirements of an ADS network have been identified, each 
application must be isolated, and a functional or performance specification 
must be described. Once this information is known, the functional 
specification of the application can be broken down into subfunctional 
groups that will describe the input parameters. These parameters are the 
user interface between the application process and the protocol of the 
application layer in the ISO model. The specification of the input 
parameter functxons can then be used to develop design specifications for 
each parameter. 

( 3 ) Develop design specifications of output strings/packets/message 
blocks for each application to be supported (output "from 6 to 5"). 

Pilot implementation of the identified application functions (e.g., remote 
catalog manager request/ response, file transfer, process initiation, and 
user message exchange) requires detailed specification of the strings, 
packets, and/or message blocks which will be output from one host system's 
layer 6 protocol function for input to another host. Currently, with the 
exception of file transfer, no federal standards exist to guide the design 
effort needed by the ADS pilot system to provide mutually compatible 
services for these functions. 

Detailed descriptions of the information content, format, and layout of the 
message blocks to be exchanged and the encode/decode processing to be 
applied to the message blocks must be specified. 

(4) Evaluate existing layer 4 and 5 protocols, including the NBS 
proposed standard, and recommend selection for pilot system and future ADS 
use. 

The purpose of this effort is to evaluate and recommend approach for the 
implementation of the transport and session layers of the OSI. This will 
be accomplished by a review of existing pilot system implementations, 
proposed standards (e.g., NBS), and other existing protocols (e.g., SNA). 
Additional points of consideration include a cost analysis of "build versus 
buy," that portion of the pilot systems’ charter which effects the 
exploration of new technologies, the possible addition of new nodes to the 
ADS network, existing hardware and software in the centers involved, and 
the facility with which a near-term implementation may evolve into a longer 
term solution. 

The output of this task should include recommendations of technologies and 
methods for a near-term implementation and longer term analyses and studies 
pointing toward a solution for future ADS system. 
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(5) Perform a requirements analysis for the ADS at the combined layers 

1-3. 


The service requirements for the interconnection of the pilots and for 
future ADS capabilities will determine which services are best suited 
(packet switched, dedicated line, other). No new standards are required 
for these layers; ADS has to select those it needs. Traffic between nodes 
will determine service required. X.25 is not cost-effective, under current 
tariff structure, for use of more than 2 hours/day — dedicated line would be 
cheaper. Satellite communication links have to be considered for high-data 
rates. The reliance on local area networks at the member nodes has r to be 
considered for impact on the ADS network. 

(6) Specify core requirements expected for each protocol layer for 
pilots and future ADS use. 

In general, standard protocols provide a large number of options and 
services, not all of which are germane to a specific application. Because 
of this, most implementations of protocols consist of a subset of the full 
capability defined by the standard. Incompatibilities arise when different 
user systems adopt different subsets of the standards, and the logical 
intersection of the various subsets are insufficient to provide the 
necessary services. This task is concerned with developing guidelines for 
each applicable protocol which identify the core functions and capabilities 
expected from each user implementation to support the future ADS 
interconnection uses. 

10. PANEL D; STANDARDS NEEDED FOR DATA FORMATS AND DESCRIPTIONS TO 
INTERCONNECT ADS PILOTS FOR DATA SHARING 


It was the consensus of Panel D that data exchange standards should be 
developed to be of general future utility, though the near-term activity 
should be constrained to focus on the problems of interconnecting. the ADS 
Pilots. The intent is to use the three pilot nodes to evaluate the 
generalized applications of the ADS. The panel agreed that the following 
considerations were important when standards are designed: 

a. DBMS catalogs should be accessible and understandable to remote 
users (both humans and applications processors). 

b. Formatting conventions should be constrained to have minimal 
impact on existing archival data sets or on currently-generating data 
sources (e.g., Landsat) , though they should be designed to provide guidance 
for future DBMS developments. 

c. Archival data records and their data descriptions should be 
available in globally- identifiable , machine readable and interpretable form 
so that users can automatically interact with variable, non-affiliated data 
sets from remote DBMS nodes. The format of the records and descriptions 
should be machine and medium independent. 

d. Terminology must be scrupulously defined. Definitions, words, 
units and general vocabulary should be standardized. Everyone should have 
the same understanding of the same word or definition. 
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'e. Each DBMiS node should have the option to optimize its data formats 
(at the discretio:a of the local authority) as long as minimal constraints 
imposied by global standards are met. 

Panel: D recomraende'd; 

(1 ) ADS should establish a standard vocabulary of terms, units, 
descriptions, *and definitions. This must be accomplished in the immediate 
futur*e. Although the early versions of the vocabulary need not be 
comp]:ete, they must provide the foundation for enabling the definitions of 
requirements and si)ecifications to proceed. 

( 2 ) ADS shoulcl provide a machine-readable standard mechanism, which is 
medium and machine independent, for describing data content, structures, 
nume:ric representations, and character codes. It is vital that these 
definition mechanisms should be adopted as soon as possible in order to 
faciiLitate the pilot interchange of data, and in order to provide guidance 
for the future data sets which will be generated in coming years. The 
mechanisms adopted MUST be adequately defined, with user guides and 
examples, and MUST have expansion capabilities. 

( 5 ) ADS should establish a set of preferred numeric representations, a 
prei'erred character code, preferred iinits, and preferred descriptions. The 
ADS 'Vocabulary should recognize and define ALL of the used or usable codes, 
units, and descriptions which currently exist within the pilots, but a 
subset of these MUST be identified as the preferred set. 

It is highly desirable that each pilot node should perform conversions of 
those existing data elements that are not in the preferred form, thus 
reducing the number oJf conversions which must be performed by each user 
processor. 

t 

( 4 ) The consensus of the panel was that the view of each of the panel 
pai’ticipants was limited. The panel members felt that it is critical that 
the* ADS should establish a permanent, dedicated team to pursue these 
rec:ommendations further. While impractical for the panel to recommend 
detailed specific items for the team, it proposed that the following 
near-term outline be piirsued: 

a. The perman.ent team should begin by analyzing the data formats, 
codes and representations used in existing pilots. 

b. The team s’.hould analyze existing and proposed data interchange 
standards. 

c. The team should adopt or create Strawman standards for review 
by data base administrators for each pilot and associated NASA 
data base. ‘ 

d. The team should establish an ADS data standards administration 
function to .approve, disseminate, maintain and provide 
visibility for these standards. 
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e. The team should provide top-level coordination for the 
development of catalogs, in order to provide to the catalog 
designers the mechanisms for describing data sets and to 
evaluate the adequacy of the catalog structures to enable 
users to access and select data. 

1 1 . WORKSHOP CLOSING 

Before adjourning, the workshop unanimously recommended the development: of 
a standard for data product preparation to ensure quality data sets. I’he 
recommendation prepared by Richard desJardins, as given in Table 4, was 
adopted. 

The workshop emphasized that there is a lot of work to be done in the 
standards area. The panels' detailed requirements and the recommendations 
for future work are vital for the ADS program. Many of the workshop 
attendees will be called upon in the future for participation in working 
groups. 

Critique of the MITRE presentation of the ADS pilot methodologies, one of 
the intents of the workshop, was deferred to the pilots for action and 
reporting in a few weeks' time. 



Table 4 

Recommendation to OSTA on a Data Product Preparation Standard 


Users of ADS may acquire some data only to find that crucial aspects of the 
data are unknown or missing, e.g., the position and time of data taking, 
the processing steps performed, the calibration curves used. I'/hile these 
aspects are of little consequence for systems interconnection protocols, 
they may be crucial for effective utilization of the data. 

Therefore OSTA should develop a standard or guideline for Data Product 
Preparation. The intent of this standard would be to provide to data 
preparation personnel a checklist to assure the "quality” of the data as 
defined by the 1979 OSTA Data Systems Planning Workshop. The term 
"quality" was used at that workshop to signify the quality of the data 
preparation process rather than the apriori intrinsic goodness of the 
sensor data. 

The scope of the standard would include; 

0 data preparation practices (e.g., recommended quality assurance 
practices, scientific data validation techniques) 

o data labeling and annotation (e.g., source, indications of gaps, 
comments) 

0 ancillary data (e.g., position, time, solar aspect) 

o "pedigree" of the data (e.g., calibrations performed, noise 
removal technique used, algorithm applied) 

0 pointers of references (e.g., name and address of preparer, 

identification of data control documentation, reference data and 
software used including version numbers and algorithms) 
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1 .0 INTRODUCTION 


The Office of Space and Terrestrial Applications (OSTA)/Applications Data 
Service (ADS) Data Systems Standards Workshop was held at the Goddard Space 
Flight Center in Greenhelt, Maryland on May 27-29, 1981. The purpose of 
the workshop was to identify standards needed to interconnect ADS pilots 
for data sharing; to assess current pilot methodologies; and to make 
recommendations for future work. The agenda for the 3-day workshop appears 
as Table 1-1. The theme of the four workshop panel groups was "Standards 
Needed to Interconnect ADS Pilots for Data Sharing," and their topics were; 
Catalogues, Directories, and Dictionaries; User Interfaces; The Use of ISO 
Open Systems Interconnection - Basic Reference Model; and Data Formats and 
Descriptions. 

This document contains reports from the panels; summaries of the talks and 
discussion presented, which are derived from transcripts and notes taken at 
the workshop, and view graph presentation material. A list of workshop 
attendees is given in Appendix F. 

2.0 WELCOME - Paul B. Schneck, GSFC 

Dr. Paul B. Schneck opened the workshop by welcoming the participants to 
the Goddard Space Plight Center. He set the stage for the workshop by 
stressing the importance of ADS in NASA's future. He emphasized that the 
"S" in ADS stands for service, not system, and that ADS must be responsive 
to the user community. It must be seen as adding value to the data which 
are processed. Finally, it was emphasized that standards must be applied 
to ADS to heighten its usability and accessibility, and not to the user to 
be able to adapt to ADS. 

3.0 INTRODUCTION TO THE WORKSHOP - Barbara Walton, GSFC 

The near-term goal for OSTA/ADS is to provide the capability for 
interconnecting the pilots for data sharing (Figure 3-1 ). There are three 
major pilots within ADS at the present time; Oceans Pilot at JPL, Earth 
Resources Pilot at Johnson Space Center, and the Atmospheres Pilot at the 
Goddard Space Plight Center. The plan is to form a network (interconnec- 
tion) to share data between disciplines and users. The theme of this 
workshop is "Standards Needed to Interconnect ADS Pilots for Data Sharing." 
The first objective of this workshop is to establish the requirements for 
standards in the areas of (a) Catalogues, directories, and dictionaries, 

(b) User interfaces, (c) Use of ISO reference model, and (d) Data formats 
and descriptions. These topics are to be addressed by the four panels, and 
their members will be making recommendations at the close of the workshop. 

A second objective of the workshop is to review for accuracy and 
completeness the methodologies of the pilots as compiled to date and to 
make preliminary assessment of their adequacy in meeting these standards 
requirements. The final and perhaps most important objective is to make 
recommendations for future standards work and the need for continuing 
standards working groups. These are the key results expected from the 
meeting. 
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Table 1-1 


Office of Space and Terrestrial Applications/ 
Applications Data Service (OSTA/ADS) Data Systems Standards Workshop 

Theme: Standards Needed to Interconnect 

ADS Pilots for Data Sharing 

- AGENDA - 

May 27-29, 1981 
Goddard Space Flight Center 


Wednesday 

, May 

27 


8:30 

am 

Registration 


9:00 

am 

Welcome 

Paul Schneck, GSFC 

9:15 

am 

Introduction to the Workshop 

Barbara Walton, GSFC 

9:45 

am 

Background 

- OSTA Data Systems Planning Workshop 
Recommendations 

- Role of Pilots 

Dick desJardins, CTA 
Pat Gary, GSFC 

10:30 

am 

Coffee Break 


10:45 

am 

The OSTA/ADS Standards Development Process 

Barbara Walton, GSFC 

11:00 

am 

Overview of Current MITRE Effort 

Terry Kuch/Rlck Sakamoto, 
MITRE 

12:00 

pm 

Lunch 


1:15 

pm 

User Requirements for ADS Standards 

Paul Clemens , MITRE 

2:15 

pm 

Refreshment Break 


2:30 

pm 

ADS Pilot Methodologies as Candidates 
for ADS Standards 

Paul Giragosian/Tom Burns 
MITRE 

3:45 

pm 

Panel Assignments and Introduction 

Barbara Walton, GSFC 


Subject: Standards Needed to Interconnect 

ADS Pilots for Data Sharing 


Panel A - Catalogues , Directories , and Dictionaries 
Panel B - User Interfaces 

Panel C - Use of ISO Open Systems Interconnection- 
Basic Reference Model 
Panel D - Data Formats and Descriptions 
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Table 1-1 (continued) 


4:00 pm Panels Convene 

6:30 pm Dinner - Speaker: James Burrows, Director 

Institute for Computer Science and Technology 
National Bureau of Standards 

Mr. Burrows will speak on the National Bureau of Standards Data Systems 
Standards Program. 


Thursday, May 28 

9:00 am Panels Reconvene 

10:30 am Coffee Break 

12:00 pm Lunch 

1:15 pm Panels Reconvene 

3:00 pm Refreshment Break 

3:15 pm Joint Discussion of Panels! Progress 

4:00 pm Panels Reconvene 


Friday, May 29 


9:00 

am 

Panels Reconvene 

10:00 

am 

Panel Reports and Joint Discussion 

11:30 

am 

Conclusions 



- Workshop Summary 

- Action Items 

12:00 

pm 

Ad j oum 


Barbara Walton, GSFC 
John Kiebler, NASA HQ 
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NEAR-TERM GOAL FOR OSTA/ADS - PROVIDE THE CAPABILITY FOR INTERCONNECTING 
THE PILOTS FOR DATA SHARING 


OBJECTIVES OF THE OSTA/ADS DATA SYSTEMS STANDARDS WORKSHOP - MAY 1981 

1. ESTABLISH REQUIREMENTS FOR STANDARDS IN THE FOLLOWING AREAS 
A - CATALOGUES, DIRECTORIES, AND DICTIONARIES 

B - USER INTERFACES 
C - USE OF ISO REFERENCE MODEL 
D - DATA FORMATS AND DESCRIPTIONS 

2. REVIEW THE COMPILED METHODOLOGIES OF THE PILOTS FOR ACCURACY AND 
COMPLETENESS AND MAKE PRELIMINARY ASSESSMENT OF THEIR ADEQUACY IN 
MEETING THESE STANDARDS REQUIREMENTS. ^ 

3. MAKE RECOMMENDATIONS FOR FUTURE STANDARDS WORK AND NEED FOR 
CONTINUING STANDARDS WORKING GROUPS. 


Figure 3-1 
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4.0 OSTA DATA SYSTEMS PLANNING WORKSHOP RECOMMENDATIONS - Dick desJardins. 
OTA ~~ 

The purpose of the OSTA Data Systems Planning Workshop held at Wallops 
Island on October 9-12, 1979 was to recommend a data system concept and 
requirements to OSTA. A great amount of time was spent trying to find out 
"What is a data system concept?" A concept includes "a means for 
identifying the work that has to be done, identifying the relationships 
between the people who had to do the work, and some kind of a 
modularization scheme for the system." The purpose of flying spacecraft is 
not to fly hardware but to build data sets from remote sensing. Panels . 
were composed of people who had problems and people who had solutions; the 
Data Systems Panel served as an integration function. All disciplines in 
the OSTA were represented as shown in Figure 4-1 . 

Figure 4-2 summarizes the Integrated Discipline Requirements identified by 
the OSTA Workshop participants as presented in the following paragraphs. 
Quality data sets are needed which are clean, useful, and processable. 
Either the project or discipline must produce parameter data sets (of 
physical phenomena) which meet the program objectives. There are problems 
with data: OSTA needs a systematic treatment of problems with present 

data. In the operations phase, scientific data management personnel should 
be responsible for the quality of the product, the planning of the product, 
and seeing that users get the data that they want. The pedigree of the 
data is important; data from a sensor are useless as is. Sun angle, 
calibration, algorithms for parameterizations, etc. are needed. 

OSTA needs a single integrated data catalog or "Master Directory." ADS 
should be one means to access the catalog to help the researcher find out 
how to get the data and avoid wasting time doing it. Since most of the 
data exist, it is estimated that these would solve over 50 percent of the 
problem. 

OSTA needs continuity of data formats. A single format is not needed; 
there should be a few, fairly standardized formats. Data levels should be 
defined. Users should be able to select the format they want. (There was 
a divergence of opinion expressed by participants. Either the formats now 
existing could be translated for the user--a value-added service — or the 
onus is on the user — he translates the data; ADS just gets the data.) 

OSTA needs to reference its data to a standard geographic and time basis. 
Every piece of data should be marked with latitude, longitude, and altitude 
(georeference). Universal Time. The user must be provided with at least a 
spacecraft clock and swath which are fundamental elements. The user also 
needs codes/algorithms , clock to UTC, geographic algorithms, etc. 

OSTA needs data delivery. Usually there is no need for immediate access to 
data. What is needed is easy accessibility : ability to get data by means 

of mail or electronic transmission. Some projects (operational 
demonstrations) have found that real-time information is useful; each 
project has a "freshness" requirement. 
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OSTA DATA SYSTEMS PLANNING WORKSHOP 



• WORKSHOP HELD OCT 9-12, 1979> AT WALLOPS 

• PURPOSE: IDENTIFY AND RECOMMEND TO OSTA AN OVERALL DATA SYSTEM CONCEPT 

FOR PROVIDING USERS OF INFORMATION FROM EARTH-WATCHING SPACECRAFT 
WITH TIMELY AND READILY USABLE RESEARCH DATA 

• 6 DISCIPLINE PANELS: AGRICULTUREj LAND RESOURCESj HYDROLOGYj 

GEOLOGY AND GEODYNAMICS j ATMOSPHEREj OCEANS 

• 5 DATA SYSTEMS PANELS: OVERALL DATA SYSTEMj ONBOARD DATA SYSTEMSj 

DATA acquisition/ DISTRIBUTION AND OPERATIONS; 

INFORMATION EXTRACTION AND PROCESSING. AND USER FACILITIES; 

DATA BASE STORAGE AND MANAGEMENT 


Figure 4-1 



INTEGRATED DISCIPLINE REQUIREMENTS 


fn 




.1 j 


1. QUALITY DATA SETS 

• PROJECTS DELIVER TIMELY QUALITY DATA SETS AS SUCCESS CRITERION 

• DISCIPLINE “PROJECTS" PREPARE QUALITY PARAMETER DATA SETS 

• RECTIFY CRITICAL EXISTING PROBLEMS 

• INVOLVE SCIENTIFIC DATA MANAGEMENT 

• PROVIDE DETAILED ANNOTATIONS. "PEDIGREE". WITH DATA 

2. DATA CATALOG (S) 

3. DATA FORMATS 

• SEVERAL STANDARD FORMATS AND LEVELS 

• USER SELECTABLE FORMATS AND LEVELS 

• REFERENCED TO COMMON GEOGRAPHIC AND TIME BASES (LAT/LONG AND UT PREFERRED) 
A. DATA DELIVERY 

5. ARCHIVE(S) 

6. COOPERATION WITH USER AGENCIES 

7. ORDERLY EVOLUTION 


Figure 4-2 



OSTA needs appropriate data archives to provide a place to store data. 

There is a need for uniformity in policy for keeping, indexing, or managing 
that data. A policy of active archives is required. Scientific data 
management should provide accessible data. 

Cooperation with user agencies is necessary for OSTA. USGS and NOAA, as 
examples, have similar needs and problems, and NASA needs to be in harmony 
with operational data from other agencies. Very few of NASA's Applications 
Programs are able to function in isolation. OSTA must implement research 
in- data input and data dissemination to meet its needs. 

Figure 4-3 shows the overall OSTA Data System Concept, a simple concept 
whose requirements include production of Level 1A data sets. Working 
storage is provided for researchers. At the level shown in the figure, ADS 
tells us what standards are necessary for making data available. ADS would 
provide consultation and a Master Directory; this workshop is an example of 
consultation. Researchers need to be able to "get to the root of the tree" 
in ADS. For long-term planning, the concept should be based on data sets. 

The overall data system concept and recommendations are shown in Figure 
4-4* The concept should be cost-accountable; it should produce Level 1A 
data sets. It could be phased over to commercial service. It was never a 
concept for electronic data dissemination. The concept included browse 
data, then place order. There was a fundamental problem with Level 1 . The 
data have to cost-effectively satisfy multiple objectives. There was a 
need for a general policy. The policy recommended was to store all the 
information that a user needs along with the raw measurement; sensor 
measurement data, sensor ancillary data, calibration with instrument, etc. 
The data must be stored in a form such that original data may be recovered. 
To do all this, OSTA needs a research and technology thrust! 
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Figure 4-3 


OSTA Data System Concept 
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OSTA OVERALL DATA SYSTEM CONCEPT AND RECOMMENDATIONS 


• OSTA OVERALL DATA SYSTEM CONCEPT 
-RECOMMENDED AS LONG TERM PLANNING BASIS 

-BASED ON DATA SETS AS INTERFACES BETWEEN PROGRAMMATIC ACTIVITIES 
-COST ACCOUNTABLE PROJECT ORIENTED DATA SYSTEMS TO PRODUCE LEVEL lA DATA 
-DISCIPLINE ORIENTED DATA SYSTEMS TO PERFORM HIGHER LEVEL PROCESSING 
-ARCHIVES TO RETAIN DATA SETS AND MAKE THEM READILY AVAILABLE 
-COMMON DATA CATALOGING AND DISSEMINATION NETWORK SERVICE 

i LEVEL 1 DAI'A 

• FLIGHT PROJECT RESPONSIBILITY 

• DISCIPLINE INFORMATION PROCESSING SYSTEMS 

• ARCHIVE(S) 

• APPLICATIONS DATA SERVICE (ADS) 

• ENDORSEMENT OF DISCIPLINE REQUIREMENTS 

• INFORMATION SCIENCE R&T 


Figure 4-4 


5.0 THE ROLE OF PILOTS - J. Patrick Gary, GSFC 


This workshop is effectively considered a working group for standards. The 
OSTA/ADS Data System Concept was described in broad terms by Richard 
desJardins. ¥e now need more detailed specification of hardware 
interfaces, communications protocols, data exchange services, etc. Hence, 
this workshop should be viewed less as a formal review committee but more 
as a working group to define areas within the data systems concept where 
standards are required. 

The overall goals of the ADS Program, as shown in Figure 5-1 , are broad. 
OSTA data users require timely and effective access to needed data in a 
uniform way. ¥e must not over standardize . OSTA has sponsored and is 
sponsoring three pilot programs deeply imbedded in the scientific 
disciplines: at GSFC, the Atmospheres Pilot involved with severe storms 

research, the VAS Demonstration project, and related atmospheres programs 
in weather and climate research; at JPL, the Oceans Pilot starting with an 
interest centered around Seasat data; and at JSC, the Resources Pilot tied 
strongly with the AgRISTARS program. 

These pilots are planned to evaluate the utilization of current techniques 
and technologies in the use and exchange of data and to facilitate, access 
to data (DBMS, Data Management, etc.). Figure 5-2 shows the common goals 
and objectives of pilots. Specifically, the pilots are to provide 
demonstrations of the use of advanced technologies, provide a test-bed 
environment for data handling technique evaluation, evolve ADS requirements 
and capabilities (long-term goal), and where applicable, document validated 
methodologies as standards and guidelines for OSTA data systems planning 
use. The pursuit of all of the above objectives is to be carried out under 
the prime directive to apply technology in a service capacity in support of 
the data handling research programs of the application disciplines. The 
three pilots, when they interconnect, have a chance to "test bed" 
distributed processing and . data sharing concepts needed to meet ADS 
near-term requirements. In time, they will come to test concepts 
applicable to much of NASA. 

Figure 5-3 shows the Promotion of ADS Concepts through Pilot Data Systems 
Activities. There must be feedback: Does the data handling concept serve 

the data users' need? Four areas relating to the technical concepts are: 

1) User-oriented catalog system, 2) Data set management, 3) Network 
communication system, and 4) User interface. 

Figure 5-4 shows the near-term requirements to be accomplished by the ADS 
Program. To interconnect the ADS pilots for data sharing, two key 
functions are needed: l) Users must know what data are available, and 2) 

Data must be exchangeable among facilities. No utopian systems are planned 
in the near-term, where processes or algorithms are exchanged or forms of 
load leveling are attempted, but these concepts may need to be addressed in 
the future. 

The relationship of pilot program activities to the standards development 
process is shown in Figure 5-5. Inputs and evaluative criticism from the 
users, pilots, and Headquarters are required in the standards development 
process. The process starts with requirements for standards, but we must 
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SUMMARY nF nVFRAl.l ADS PROGR/W 


GOAL 


- PROVIDE OSTA DATA USERS WITH TIMELY AND EFFECTIVE ACCESS TO NEEDED DATA 
AND INFORMATION WITHIN AND OUTSIDE OF NASA 

- PROVIDE STANDARDS/GUIDELINES FOR FUTURE OSTA PROGRAMS TO EVOLVE DATA 
SYSTEMS AND DATA MANAGEMENT TOWARDS COMPATIBILITY WHERE APPROPRIATE 


APPROACH 


- EVOLUTIONARY DEVELOPMENT THROUGH PILOTS TO MEET APPLICATIONS USER 
REQUIREMENTS 


OSTA/ADS PILOTS 


RTOP MANAGEMENT 


ATMOSPHERES PILOT SYSTEM GSFC 
OCEANS PILOT SYSTB1 JPL 
RESOURCES PILOT SYSTEM JSC 


CONCEPTS 


- USER ACCESS TO INFORMATION ABOUT DATA AND TO THE DATA ITSELF THROUGH 

0 APPLICATION OF DATA CATALOGING AND MANAGEMENT TECHNOLOGIES 
0 INTERCONNECTION OF APPLICATIONS DATA SYSTEMS TO FACILITATE DATA EXCHANGE 


Figure 5-1 



COMMON GnALS/ORJECTIVF.S OF nSTft/Ans PILOTS 


0 PROVIDE USEFUL DEMONSTRATIONS AND CAREFUL EVALUATIONS OF CAPABILITIES TO LINK DATA 
USERS AND PRODUCERS FOR SELECTED OSTA PROGRAMS 

0 PROVIDE TEST BEDS TO EXPLORE TECHNOLOGIES AND TECHNIQUES FOR CATALOGS. DATA ORDERING. 
DATA EXCHANGE. AND OTHER RELATED ADS CONCEPTS 

0 EVOLVE AND VERIFY THE REQUIREMENTS AND SPECIFICATIONS FOR A FUTURE FULL CAPABILITY ADS 

0 DEVELOP STANDARDS FOR OSTA DATA SYSTEMS IN COOPERATION WITH OTHER NASA PROGRAM OFFICES 

AND OTHER AGENCIES 


Figure 5-2 



PROMOTION OF ADS CONCEPTS 


THROUGH PILOT DATA SYSTEMS ACTIVITIES 



ADS TECHNICAL CONCEPTS 


0 USER ORIENTED CATALOG SYSTEM 

- INFORMATION CONTENT/ORGANIZATION 

- CREATE/UPDATE CATALOG ENTRIES 

- INTERACTIVE CATALOG ACCESS 

- CATALOG ACCESS SECURITY 


0 NETWORK COmUN I CATION SYSTEM 

- HIGH AND LOW SPEED LINES 

- ISO LAYERED DATA SYSTEM INTERFACES 

- USAGE STATISTICS MONITORING 

- GATEWAYS TO OTHER NETS 


0 DATA SET MANAGEMENT 

- ON-LINE/OFF-LINE STORAGE 

- FILE PROTECTION/ACCESS PRIVILEGES 

- SELECTIVE DATA SUBSETTING 

- DATA EXCHANGE FORMATS 


0 USER INTERFACE 

- HELP FUNCTIONS 

- LOCAL/REMOTE CATALOG QUERY 

- DATA SET ACCESS/EXCHANGE 

- LOCAL/REMOTE PROCESS INITIATION 



Figure 5-3 








NEAR-TERM ADS REOIITRFHFHT!; 


INTERCONNECT ADS PILOTS FOR DATA SHARING 

- PROVIDE USER ACCESS TO INFORMATION ABOUT 

AVAILABLE DATA 

- PROVIDE DATA SET ACCESS/EXCHANGE/DISSEHINATION 

AMONG SYSTEMS 


Figure 5-4 



RELATIONSHIP OF OSTA/ADS PILOTS TO THE STANDARDS DEVELOPMENT PROCESS 


OTHER SOURCES 


STANDARDS 

REQUIREMENTS 


NEEDS OF PILOT PROJECTS 


EXISTING STDS ZIZ 
& GUIDELINES 


ANALYSIS 


METHODOLOGIES 


/ OSTA/ADS PILOTS 

Applications data systems/ 

TECHNIQUE DEVELOPMENT, TEST 
AND EVALUATION 


EVALUATION 


STANDARDS 

ESTABLISHMENT 


REQUEST FOR 
TEST/DEVELOPMENT 


SPECIFICATIONS 


OSTA/ADS 
STANDARDS & 
GUIDELINES 


Figure 5-5 



overstandardize. Standards are useful to describe 1) How to describe; 
2 ) How to build; and 3) How to apply. Should ADS find that the current 
standards or methodologies are not adequate or applicable to its needs, the 
pilots can test new methodologies or proposed standards and develop them. 
The establishment and dissemination of standards is a high level management 
function (OSTA, NASA). A result of this standards development process 
feeding back to the pilots will be standards useful to the design and the 
specification of new systems. 

Figure 5-6 shows the overall ADS development approach with its gradual 
expansion of capabilities. The process is iterative; feedback to and from 
working groups, such as a standards development working group, is essential 
for progress. FY84 is planned as a target completion date for the 
development of an ADS working model. 
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6.0 THE OSTA/ADS STANDARDS DEVELOPMENT PROCESS - Barbara Walton, GSFC 

The goals of the OSTA/ADS Data Systems Standards Program were formulated in 
response to the need for standards for sharing data. The overview of the 
program is shown in Figure 6-1 . Applicable standards of the National 
Bureau of Standards and other existing standards can be used, but ADS and 
OSTA have unique problems. NASA has already dealt with some of the unique 
problems, such as the Landsat images CCT (Computer-Compatible Tape) 
standards; however, there are other development efforts that NASA will be 
dealing with in the near future. The coordination with the OSTA programs 
and the pilots is an objective of the Program. 

Figure 6-2, dated August 1979, lists the requirements for the OSTA data and 
data systems standards at that time. In August of 1980, I began work on 
ADS standards and developed a phased approach to the problem. In FY82 and 
FY83 the focus will expand to include all OSTA data systems. Hopefully, in 
Fy84 and beyond there will be a "full" OSTA/ADS Standards and Guidelines 
production. 

Resources of the OSTA/ADS Data Systems Standards Program are shown in 
Figure 6-5, which is an organization chart of parts of NASA. At Goddard we 
have standards efforts in Cataloging, under Karen Posey; PADS is directed 
by Pat Gary; Dave Howell is the head of TAE; and, the GSFC Aerospace Data 
Systems Standards Program (not shown) is directed by Bill Poland. 

The three phases of the Approach to OSTA/ADS Data Systems Standards Program 
are shown in Figure 6-4. What has been done? The standards survey, user 
requirements, methodology survey, and evaluation criteria are all FY81 
Phase 1 projects. "Candidate" standards will be produced and the results 
are due to be published in August of this year. The following remains to 
be done: ADS planning, interim standards, a concept for implementation of 

a "Core ADS", definition of OSTA data systems policy, and full-capability 
ADS definition. 

Results are shown in the Phase 1 (Figure 6-5) chart. This is basically 
this year's program which builds on the results of the OSTA Workshop and . 
the feasibility study reported on by Dick desJardins. Standards surveys, 
examination of pilot methodologies, and criteria development have been 
done. At the workshop today we hope to review/modify/ evaluate these 
processes so that those standards which might be applicable to ADS may 
become candidate standards for ADS. 

Figure 6-6, Phase 2, shows the expanded focus on OSTA data systems and 
"Core ADS." Figure 6-7, Phase 5, focuses on the future goal of a 
"full-capability ADS." Once we get a full set of standards, we will need 
to have a systematic review and periodic update. Standards will evolve as 
needs evolve; the ADS effort will continue to grow. 
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nATA .^Y.STFMS STANDARDS AND GUIDFLINES PROGRAM OVE R VIE H 


GOAL 

• PROVIDE EFFECTIVE DATA EXCHANGE AND DATA SYSTEM INTERFACE 
STANDARDS AND GUIDELINES FOR OSTA PROGRAMS 


OBJECTIVES 

• IDENTIFY AND RECOMMEND USE OF DATA SYSTEM STANDARDS AND 
GUIDELINES APPLICABLE TO OSTA/ADS 

• DEVELOP AND MAINTAIN OSTA/ADS - UNIQUE DATA SYSTEM 
STANDARDS AND GUIDELINES 

• COORDINATE WITH OSTA PROGRAMS. ADS PILOTS AND PERTINENT 
STANDARDS ACTIVITIES WITHIN AND OUTSIDE NASA 


Figure 6-1 



DSTA DATA AND DATA SYSTEMS STANDARDS REQUIREMENTS 


t USER TERMINALS (INTERFACES AND VIRTUAL TERMINAL PROTOCOLS) 

0 DATA SYSTEMS (FILE STRUCTURE. DATA MANAGEMENT. AND ACCESS PROTOCOLS) 

• FORMATS (DATA REFERENCE FRAMES-GEOGRAPHIC. TEMPORAL; DATA FORMATS. 

CODES AND CONVENTIONS INCLUDING GEOCODING STANDARDS) 

0 LANGUAGES (INTERACTIVE DATA QUERY LANGUAGE. DATA DESCRIPTION LANGUAGE- 
DATA DICTIONARY) 

0 DIRECTORIES/CATALOGS (PRODUCER AND USER DATA SOURCES AND PRODUCT LISTS 
WITH LOCATIONS AND ACCESSING INFORMATION) 

0 INTERCONNECTION (NETWORK PROTOCOLS. INTERFACES. AND GRADES OF SERVICE) 

0 DATA PREPARATION (STANDARD LEVELS OF VALIDATION PERFORMED AND CERTIFICATION 

CRITERIA; STANDARD DEFINITIONS OF INFORMATION LEVELS) 

0 SOFTWARE (SOFTWARE ENGINEERING STANDARDS. STANDARDS OF DOCUMENTATION) 


100.7 8/13/79 
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OSTA/ADS DATA SYSTEMS STANDARDS PROGRAM 
WORKING RELATIONSHIPS 
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APPROACH TO OSTA/ADS DATA SYSTFnS STANDARDS PROGRAM 


PHASE 1 - FY81 

FOCUS ON ADS 
ASSESS REQUIREMENTS 

SURVEY EXISTING STANDARDS AND GUIDELINES 
EXAMINE PILOT METHODOLOGIES 
DEVELOP STANDARDS EVALUATION CRITERIA 
PRODUCE "CANDIDATE" STANDARDS AND GUIDELINES 

PHASE 2 - FY82 AND 83 

EXPAND FOCUS TO OSTA 

DEVELOP IMPLEMENTATION AND MAINTENANCE PROCEDURES 

SPECIFY MAJOR STANDARDS DEVELOPMENT EFFORTS FOR NEAR-TERM ADS GOALS 

PRODUCE "INTERIM" STANDARDS AND GUIDELINES FOR "CORE ADS" 

PHASE 3 - FY8^ AND BEYOND 

CONTINUE STANDARDS REQUIREMENTS ASSESSMENT 
EVALUATE STANDARDS AS TESTED IN PILOTS 

PUT IN PLACE IMPLEMENTATION AND MAINTENANCE PROCEDURES. REVIEW BOARDS 
AND POLICY 

PRODUCE OSTA/ADS DATA SYSTEMS STANDARDS AND GUIDELINES CAPABLE OF 


SUPPORTING "FULL" CAPABILITT' ADS 

Figure 6-4 
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OSTA/ADS DATA SYSTEMS STANDARDS PROGRAM 

PHASE 1 - ADS FOCUS 



Figure 6-5 








OSTA/ADS DATA SYSTEMS STANDARDS PROGRAM 
PHASE 2 - OSTA/CORE ADS FOCUS 
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STANDARDS 

POLICY 
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OSTA/ADS DATA SYSTEMS STANDARDS PROGRAM 
PHASE 3 - OSTA/FULL ADS FOCUS 
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7.0 OVERVIEW OF THE CURRENT MITRE EFFORT - Terry Kuch/Rick Sakamoto, MITRE 


Following is a summary of the first of three MITRE presentations at the 
workshop. View graphs used in this presentation are reproduced in 
Appendix A. 

Terry Kuch and Rick Sakamoto presented ^an introduction to MITRE' s support 
of the OSTA/ADS standards and guidelines program. The three MITRE 
presentations at the workshop dealt primarily with functions needed for 
near-term data sharing among ADS member systems. Sharing of computational 
facilities and software were considered to be longer-term ADS goals. 

MITRE adopted a logical view of ADS as a distributed system, which 
distinguishes among seven components of such a system: 

0 Members 

1 ) Providers of data 

2) Providers of applications software 

3) Providers of computational facilities 

4) Users of data, software, or computational facilities 
0 Support services 

5) Administrative services 

6) Technical services such as documentation and location support' 
for data, software, and computational facilities 

7) Support for data communication 

Based on this logical view, MITRE developed a hierarchical classification 
scheme of ADS features at a level of detail (70 nodes) appropriate to the 
level of detail addressed by most Federal, national, and international 
information processing standards. 

This feature classification provided' the framework for a preliminary 
assessment of the applicability of Federal, national, and international 
standards to ADS. These standards were gathered, screened, and documented 
briefly. Some 300 standards were examined, of which 187 were reported in 
NASA contractor report CR 166675. ' 

This survey of standards was enlarged to incorporate standards from NASA 
Headquarters and centers. At the same time, two key efforts were 
initiated to: 

0 Survey methodologies of the three ADS pilots. 

o Identify the requirements for standards of ADS members based on 
a survey of the pilots and on representative potential future 
members. 
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Preliminary results of the requirements survey were used in the development 
of criteria for the evaluation of candidate standards for OSTA/ADS. An 
evaluation process was designed incorporating these criteria. 

An overview of the evaluation process was presented in this session, and 
examples of candidate standards were passed through the process, 

7.1 GOALS OF THE SESSION 

The goals of this session Were to familiarize those attending the workshop 
with mitre's work in support of ADS, and to invite comment on this work, 
especially on; 

o Applicable standards 

o Evaluation process 

o Evaluation criteria 

7.2 PRESENTATION DISCUSSION 

Dr. Adrian Hooke asked, "With reference to view graph 4, what happens when 
you do items 5 and 4 and find a requirement for standards that doesn' t fit 
in item 5?" * 

Terry Kuch replied that in this case a standard should be developed outside 
the flow shown in the diagram, perhaps under contract. 

Richard desJardin commented that*the principal recommendation of the OSTA 
Data Systems Planning Workshop is missing from the current standards effort 
- QUALITY DATA SETS. The main thing programmatically you have to tell 
people is what constitutes quality. 

Quality is; Description 

Annotation and Pedigree 

Certification and Algorithms used to process the data 
Where is the policy standard? 

William Shaffer replied that it is a policy standard. There are two points 
to be made here; First, it hasn't been done [in the past]. Second, 

Goddard has changed that and it is being done — for 3 months already. 

Project Managers are responsible for their data — for quality data. Bob 
Lynn has solved this. 

After further discussion, which pointed out that the current effort is on 
ADS and that this is an OSTA problem, Richard desJardin agreed to draft a 
recommendation for consideration by this workshop which was later adopted 
in the closing session (see Section 15.0). 
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Anthony Villasenor commented that NASA Headquarters takes the position that 
the purpose of this workshop is to evolve standards for ADS. The OPEN/UARS 
programs point the way. There is a need for creating data and the 
management of data — a realizable goal. We hope the workshop will give 
input to which standards will be policy, which will be technical. 

William Poland observed that the chart on characteristics is deficient and 
needs augmenting. 

Gerald Knaup commented on what is and is not a standard — we don' t have a 
standard catalog, rather we want to look at a number of technologies to 
implement. We can then come up with areas and a cooperative agreement, not 
a rigid standard. 

Tony Villasenor said that for the full ADS, Headquarters needs and expects 
a commercialized service. A specification on this service is needed for an 
ADS interconnection. We will need it by Phase 3* The ultimate ADS will be 
a commercial service, not government service. 
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8.0 USER REQUIREMENTS FOR ADS STANDARDS AND GUIDELINES - Paul Clemens, 
MITRE 

Paul Clemens presented the results of a survey of ADS member requirements 
for standards and guidelines; his view graphs are in Appendix B. This 
survey was carried out in four steps: 

o Identify a representative number of planned and prospective ADS 
members from ADS pilots, key OSTA programs, and other sources. 

o Survey the identified members. 

0 Define and document members' needs for ADS system capabilities and 
services. 

0 Derive ADS standards and guidelines requirements from this survey 
of members' needs. 

The survey included the interpretation and analysis of functional 
requirements from three sources: (l) earlier OSTA/ADS data system studies, 

( 2 ) current ADS pilot activities, studies, and documentation, and ( 3 ) 
prospective ADS members' activities and documentation. Requirements in 
each case were then reviewed and modified as needed to reflect the overall 
scope of ADS. 

The resultant requirements were then tabulated and mapped into the ADS 
feature classification. The findings were analyzed for commonality of 
purpose and function and, from this analysis, overall standards 
requirements were determined. 

This session prioritized requirements in the areas to be addressed by the 
workshop panels: data catalogs, user interfaces, the ISO model for open 

systems interconnection, and data formats. 

8.1 GOALS OF THE SESSION 

The goals of the session were to elicit comments on the adequacy of MITRE' s 
findings, especially as to: 

1 ) Functional areas requiring standards, 

2 ) Utility and applicability of the identified requirements for 
standards, 

3 ) Completeness of the survey as presented, and 

4 ) Any misrepresentations in the survey and analysis. 

8.2 PRESENTATION DISCUSSION 

A question from the audience at the end of view graph 50: Is it more 

fruitful to describe data formats and not data elements? One may argue the 
point that some need data elements described, too. A solution might be to 
say rather, that it is "sufficient for standardization requirements." 
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Paul Clemens agreed that this is a good point. 

Another question asked from the audience: If you know what to do, do you 

carry it out in an optimum way — on the satellite, ground, or air? 

Barbara Walton replied that ADS does not preclude doing sorting (for 
example) on the spacecraft. 
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9.0 ADS PILOT METHODOLOGIES AS CANDIDATES FOR ADS STANDARDS - Paul 
Giragosian, MITRE ” ~ 


The third MITRE presentation was made by Paul Giragosian; his view graphs 
are in Appendix C. 

At various stages in their development, the ADS pilots have implemented or 
planned to adopt certain practices, procedures, standards, or conventions. 
The collection of these practices as applied toward a specific development 
function or operational objective constitutes the notion of a 
"methodology." 

This session presented the results of a survey of the methodologies 
employed by the ADS pilot programs (Atmospheres, Oceanic, Earth Resources). 

MITRE surveyed, identified, and documented methodologies for each of the 
ADS pilot systems. Major methodology categories include: 

0 Methods for system interconnection 

o User interface 

0 System directory/ catalog structure 
0 Data definition/structure 

The primary objective of the survey was to provide an information base for 
the evaluation of these methods and their applicability to the future 
development of ADS standards and guidelines. 

An illustrative example of Pilot communications methodologies follows: 

The Pilot Atmospheres Data Systems (PADS) has been implemented on three 
Digital Equipment Corporation (DEC) applications processors: two PDP 

11/70 and a VAX 11/780 in a star configuration with a DEC PDP-11/34 
functioning as the central communications processor. User terminals are 
hardwired to the applications processors. 

Communication is accomplished using the Remote Services Subsystem (RSS) and 
a communications software package, COMM. These software packages were 
developed specifically for PADS. On-site processor communication uses the 
Digital Data Communications Message Protocol (DDCMP) while off-site 
communication will use a subset of the ANSI Advanced Data Communications 
Control Procedure (ADCCP) protocol. 

The Earth Resources Pilot uses the IBM bisynchronous protocol with the IBM 
communications package. Remote Spooling and Communications Service (RSCS) 
to transmit and process data sets within the Earth Resources Data 
Applications Network. The network is composed of two host processors: an 

IBM 3031 with a front-end 3670 COMTEN communications processor at Purdue 
University and an AS/ 3 OOO with a front-end 3650 COMTEN communications 
processor at the Johnson Space Center. Two 9600-baud lines connect the 
hosts. User communication is accomplished using 300-baud and 1200-baud 
lines asynchronously linked to either host. 
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The Oceanic Pilot System hardware configuration consists of a DEC VAX 
11/780 with a PDP 11/44 serving as a front-end communication processor. 
Users communicate via 300-bit/sec and 1200-bit/sec asynchronous lines. The 
system will utilize Digital Equipment Corporation's DECNET communications 
software. 

9.1 GOALS OF THE SESSION 

The goal of the session was to obtain critical assessment of the 
completeness and accuracy of the pilot methodology survey. 

9.2 PRESENTATION DISCUSSION 

Following view graph 8 on PADS, a member of the audience asked if the 
Communications Package (COMM) of the Pilot Atmospheres Data Package (PADS) 
will be tied to commercial use. 

Paul Giragosian replied that both COMM and RSS (Remote Services Subsystem) 
serve layers within the OSI model and will also be used as a basis for 
interfacing with a commercial network. 

Bill Shaffer asked how far along the PADS/System of Networked Applications 
Processors (SNAP)is. 

Paul answered that it is now running in the current initial configuration. 

Bill Shaffer asked about the need for standards for SNAP. 

Pat Gary replied that dissimilar DBMS exchange has demonstrated that a 
file format structure standard was needed. The Pilot Climate Data Base 
Management System (PCDBMS) will manage different information. This is also 
a problem. So we really need standards now. 

A member of the audience commented (after view graph 21 on PADS attribute 
mapping) that the PADS "Superset" approach works for a smaller set and 
asked, "What is now meant by a 'small' set? Big?" 

Dr. Samuel Steppel replied that there are 200 bytes per slot. About 60 
spare attributes now exist (some in 2, 4, 8-byte attributes). The 
advantage is that each system worries only about its own attributes — no 
translation. If we had lots of data though, it is no good. 

Portia Bachman asked, in reference to view graphs 30 and 31 > how the data 
base for all of ERPS is accessed. 

Paul answered that we use CMS to get the catalog. Then we use the catalog 
to search the entire data base. 

Edward Greville asked (after view graph 37) if DECNET currently supports 
PCL-1 1 . 

John Johnson answered that the present phase of it does. 
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Pat Gary (after view graph 40) commented; "You [at OPS] won't use it 
[SFDU] internally? Vfhy abandon it?" 

John Johnson replied that we will probably use what's already there because 
of convenience. 

Dr. Dennis Fife, (after view graph 55) asked if there is any precedence or 
prototype for this SFDU. 

Dr. Edward Greenberg stated that we will steal from any standard that 
exists. There is a draft in the MSA Office of Advanced Space Technology 

(oast). 

Adrian Hooke commented that we are trying to draft this as a new standard. 

Someone from the audience asked why this is highlighted if it is not being 
used? How do you pace this development? Before JPL puts out standards, we 
should take a breath. 

Adrian commented that this [SFDU] was mission unique but this uniqueness 
will go away. 

Ed Greenberg commented that this was to be used to use data; it is an 
expandable set. You hope to have it in a good form for cataloging. We are 
still in the process of understanding how to pick a version. 

After the conclusion, someone in the audience asked how the strengths [of 
the pilots] were developed, and was answered that the goals of the pilots 
conditioned these. As an example. Dr. James W. Brown commented that the 
thing that drove OPS was the idea of the pilot as a data archive (active), 
with active access to subsets. The idea of data management gives the 
impression of a large number of small data sets . . . whereas Oceans Pilot 
has a small number of very large data sets. The pilots are just different. 

Ed Greene stated that he has sympathy with the SFDU approach but the 
concept is still immature. Trying to impose a structure now would stifle 
the innovation. It's still developing. 
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10.0 PANEL ACTIVITIES 


Barbara Walton presented the introduction to the panels as shown in Figure 
10-1. She then gave the panel assignments as shown in Figure 10-2. The 
panels convened briefly before breaking for dinner. 

James Burrows, Director of the Institute for Computer Science and 
Technology of the National Bureau of Standards, was the dinner speaker on 
the first day of the workshop. He discussed the NBS Data Systems Standards 
Program and emphasized the communications protocol development program. 

He offered an inside view of the European Standards effort and noted that 
U.S. companies use Europe as a forum due to anti- trust laws. He explained 
the National Telecommunication Information Administration (NTIA)/National 
Bureau of Standards (NBS) relationship within the Department of Commerce. 
One comparative example illustrated that government communication services 
such as telephone, telegram, and postal services are handled by one 
government entity in most European countries, while in the United States 
standards development for such services would go through the State 
Department. 

The panels continued their work on the following day with presentations 
given by the panel chairmen on the last day of the workshop. The panel 
reports follow in Sections 11 through 14. 
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OSTA/ADS DATA SYSTEMS STANDARDS WORKSHOP 
INTRODUCTION TO PANELS 

"STANDARDS NEEDED TO INTERCONNECT ADS PILOTS FOR DATA SHARING" 

li CRITIQUE THE MITRE REPRESENTATION OF PILOT METHODOLOGIES FOR ACCURACY 
AND COMPLETENESS. 

2. IDENTIFY THE REQUIREMENTS FOR STANDARDS AND GUIDELINES NEEDED IN YOUR 
PANEL'S AREA TO INTERCONNECT THE ADS PILOTS FOR DATA SHARING, 

3. MAKE A PRELIMINARY ASSESSMENT OF THE ADEQUACY OF CURRENTLY IDENTIFIED 
PILOT METHODOLOGIES AND EXTERNAL STANDARDS IN MEETING THESE REQUIREMENTS. 

A. IDENTIFY ANY OTHER METHODOLOGIES YOU ARE AWARE OF WHICH HAY CONTRIBUTE 
TO THE SOLUTION TO YOUR PANEL'S ASPECT OF THE PROBLEM. 

5. MAKE RECOMMENDATIONS FOR FUTURE WORK. PROVIDING DESCRIPTIONS AND ESTIMATE 

I 

OF EFFORT WHERE POSSIBLE. 

6. PROVIDE THE PANEL'S CONSENSUS ON THE NEED FOR A CONTINUING WORKING GROUP 
IN THIS AREA AND SUGGEST MEMBERSHIP THEREOF, 


Figure 10-1 



STANDARDS NEEDED TO INTERCONNECT ADS PILOTS FOR DATA SHARING 

PANEL ASSIGNMENTS 

ROOM 205 FRONT PANEL A - CATALOGUES. DIRECTORIES. AND DICTIONARIES 

CHAIRMAN; JOSE URENA. JPL - FTS 792-3A28 


ROOM 1A7 PANEL B - USER INTERFACES 

CHAIRMAN; JIM BROWN. JPL - FTS 792-5109 

ROOM 200 PANEL C - USE OF ISO OPEN SYSTEMS INTERCONNECTION 

BASIC REFERENCE MODEL 
CHAIRMAN: ED GREENE. GSFC - 3il4-8685 

ROOM 205 BACK PANEL D - DATA FORMATS AND DESCRIPTIONS 

CHAIRMAN: ED GREENBERG. JPL - FTS 792-3387 


Figure 10-2 



11, .0 PANEL A REPORT; STANDARDS NEEDED TO INTERCONNECT ADS PILOTS FOR DATA 
SHARING~FOR CATALOGUES, DIRECTORIES, AND DICTIONARIES" 


11.1 INTRODUCTION 


One of the primary goals of the OSTA/ADS concept is to provide the user of 
the ADS service with coherent and comprehensive information about the data 
that may he of interest to him. This information about the data (sometimes 
called "metadata"), is usually made available in the form of electronic or 
printed catalogs, dictionaries or directories. The objectives of this 
panel were to specify the requirements for the minimum set of standards 
that are necessary for an effective sharing of information about data among 
all the ADS member installations. 

The meetings of the panel took place during the May 27-29, 1981 OSTA/ADS 
Data Systems Standards Workshop, and its membership consisted of the 
following: 


Jose Urena, JPL, Chairman 

Manju Bewtra, CSC 

Steve Haight, ORI 

Stan Klein, ORI 

Lou Kramer, LARS 

Terry Kuch, MITRE Corp. 

11.2 REQUIREMENTS FOR GUIDELINES 


Roy Saltman, NBS 
Peter Smith, GSFC 
Ellen Stolarik, OAO Corporation 
Frank Stone, OAO Corporation 
Barbara Walton, GSFC 

James Wilkinson, Lockheed Corporation 
TD STANDARDS 


The panel identified a preliminary set of requirements for guidelines and 
standards that are described below* These requirements will be revised and 
will eventually be used to develop guidelines and standards in subsequent 
working sessions of the panel. 

11.2.1 Layered Directory /Patalog Architecture and Definition of Terms 

The panel found it necessary to identify and define a top-level repository 
of information about data upon which standards can be specified. The term 
assigned to this "highest" level repository is "DIRECTORY." 

DIRECTORY Definition: High-level description of data sets 

available to all ADS users. The directory is accessed by means 
of a standard user interface. 
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The detailed information about data resides in the "lowest" level 
repository. The term "LOCAL CATALOG" was assigned to it: 

LOCAL CATALOG Definition: Detailed description of data 

sets. The local catalogs are maintained by the organization 
that is also responsible for maintaining those data sets. 

The structure below the directory may contain intermediate levels of 
directories which are both local- and network- implementation dependent. 
This potential requirement was not addressed by the panel. 

The above definitions identify a structure with at least two levels. 
Standards in the near-term need only to be specified for the top level 
(DIRECTORY). 


The ADS Directory/Catalog architectural model is depicted in Figure 11-1. 
The user accesses the information in the directory by means of a standard 
user interface, and logical links connect the directory with the local 
catalogs or with the intermediate level directories. The dashed lines show 
possible future logical links between the user and the local catalogs, 
intermediate directories, and data sets, that would require new standard 
interfaces. These interfaces are not being considered for ADS at the 
present time, and they were not addressed by this panel. 

Only those terms needed to support the model presented here have been 
defined by the panel. The use of other terras such as inventory, or 
terminology for intermediate directories is to be determined. 

The use of terms presented here is compatible with the National Bureau of 
Standards terminology, and it is consistent with some concepts used by the 
International Standards Organization in the Reference Model for Open 
Systems Interconnection. 

The panel also agreed on the definition of the following term: 

ATTRIBUTE Definition: A data element of a directory or a 

catalog, [reference: FIPS PUB 20 for definition of the 

data element. (l)]* . 


(l ) DATA ELEMENT: • A basic unit of identifiable and definable information. 

It has an identifying name and value or values for expressing a specific 
fact. 
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11*2.2 Standards Required for the DIRECTORY 

The following is the set of requirements for standards that were identified 
for the directory by Panel A: 

a. Contents 

1 • Temporal and spatial coverage 
2. Data type 
3* Source ■ 

4* Responsible organization 

a. Data generation 

b. Data production 

c. Data archival 

5. Status (existing/planned) 

6. Data level 

7. Etc. (to possibly include an extensive list of additional 
items) . 

b. Structure 

1 . Standard format 

2. Attribute representation 

c. User Interface 

1 . Common query method 

2. Interactive search of logical combinations of attributes and 
their values. All attributes are searchable. 

d. Interface to lower levels 

1 . Short term: identification of local catalogs or intermediate 

level directories 

2. Long term: transparent to user 
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e. Administrative responsibilities, policies and. procedures 
1 . Currency of directory 

2. Quality assurance of directory 

3. Access control 

11.2.3 Definitions/Conventions for Terminology 'of Directory Attributes 

11.2.4 Guidelines for the Local Catalog 

The diversity of implementations and the peculiarities of the local 
catalogs used by the different ADS member organizations makes 
standardization of the local catalogs unfeasible. The panel, however, has 
identified a set of guidelines that can be specified for the local catalog: 

a. Functions 

1 . Provide detailed description of data sets 

2. Assist in obtaining access to the data 

b. Document structure, access methods, etc. 

c. Should provide definitions of terms used to describe the data 
sets. 

d. Provide definitions/descriptions of data formats and code 
conventions, etc. (see FIPS Pub. 20) . 

e. Contents should include an amplification of items 1 , 2, and 3 
under directory contents. 

11.2.5 Directory User's Guide 

11.3 RECOMMENDATIONS 

11.3.1 Need for a Continuing Directory/Catalog Standards Working Group 

a. Functions of the Directory/Catalog Standards Working Group: 

1) Advise the ADS Standards Program on Directory/Catalog 
matters. 

2) Provide advisory review of contractor products related to 
Directories and Catalogs. 

b. Membership should include at least one representative from 
each one of the pilots and the OSTA/ADS Standards Program. 

c. The group should consider the need for a standard user interface 
to local catalogs and intermediate directories. 
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d. Investigate methods for incorporating terminology definitions 

accepted by recognized discipline user bodies. 

^"'•5*2 Need for a Directory/Catalog Implementation Working Group 

a. Assessment of current ADS pilot methodologies to be done in 
the future. 

b. Studies for alternative implementation methods of the 
directory. Selection of one. 

c. Detailed design of the directory. 

d. Determination of software functional requirements. 

e. Design interface between directory and local catalogs of. 
pilots. 

f. Consideration of library and information science methodologies 
for its relevance. (See panel references.) 

g. The directory could allow structured data retrieval and 

retrieval of unstructured indexed textual information. 

. • 

11*3.3 Further Recommendations 

a. Policy be set concerning the release of information about data 
to ADS. 

b. Adoption or modifications of the WALLOPS definitions for data 
levels (under area of work of Panel D on Data Formats and 
Descriptions) . 

c. There is a need for continuing discipline user working groups. 

d. Study alternatives to "in-person" meetings. 

11.4 PANEL A PRESENTATION DISCUSSION 

Pat Gary asked if it matters if the Directory is centralized. 

Jose Urena answered that it is immaterial. 
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11.5 PANEL A REFERENCES 


The following citations contain concepts relevant to the issues in the ADS 

directory system from a library and information science perspective. 

1. Svenonuis, Elaine, "Directions of Research in Indexing, Classification, 
and Cataloging," Library Resources and Technical Services , Jan. /Mar. 
1981, pp. 88-103. 

2. Foskett, Anthony C., The Subject Approach to Information , 3i’d ed. , 
Hamden, Conn., 1977. 

3. Lancaster, Frederick ¥., Vocabulary Control for Information Retrieval , 
Washington, D.C., 1972. 

4. Thesauri and Thesauri Construction; ASLIB Bibliography No. 7 , Compiled 
by Maxine MacCafferty, ASLIB London, 1977* 

5. Kazlauskas, Edward J. , "The Application of the Minicomputer to 
Thesaurus Construction," Journal of the American Society for 
Information Science , Sept. 1980, pp. 363-368. 

6. "On Indexing, Retrieval and the Meaning of About," Journal of the 
American Society for Information Science , Jan. 1977, pp. 38-43* 

7. The Information Age in Perspective; Proceedings of the ASIS Annual 
Meeting 1978 , Vol. 15, 41st Annual Meeting. 

8. Report on the Conference on Cataloguing and Information Services for 
Machine-Readable Data Files , Airlie House, Warrenton, VA, March 29-31, 
1978, Arlington, VA, Data Use and Access Laboratories, 1978. 


NOTE: Citations 1-7 were provided by Jody Engbretson, ORI. 
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12.0 PANEL B REPORT: STANDARDS NEEDED TO INTERC ONNECT ADS PILOTS FOR 

DATA SHARING FOR USER INTERFACES ^ 

12.1 INTRODUCTION 

Some key elements recommended prior to the workshop for the panel's 
consideration were; ( 1 ) Dial-up procedures, ( 2 ) Terminals (minimum, 
desirable, extended capability), (5) Common capabilities, ( 4 ) Language 
interfaces (query, command, menu), and ( 5 ) Display capabilities. It was 
the group's goal to identify the requirements for standards and guidelines 
with regard to user interfaces for the near-term interconnection of the 
pilots, bearing in mind that it must not cause any long-term problems. The 
key elements listed were considered though not always as separately 
identified topics. 

The meetings of the panel were held on May 27-29, 1981 at the Goddard Space 
Flight Center OSTA/ADS Data Systems Standards Workshop, and its membership 
consisted of the following; 

James ¥. Brown, JPL, Chairman 

Portia Bachman, GSFC 

William Benton, Lockheed Corporation 

Paul Giragosian, MITRE Corporation 

Ronald Glaser, CSC 

David Howell, GSFC 

Richard Sakamoto, MITRE Corporation 

William Shaffer, NASA Headquarters 

David Stowell, OAO Corporation 

12.2 DEFINITION OF USER 

The "user," as defined for the purposes of this panel, though not 
necessarily for the purpose of the whole workshop, is viewed as a 
discipline scientist at a terminal trying to get data out of the network. 

It is assumed that the user is primarily associated with one of the local 
systems, such as VAS or the Ocean Pilot. 

12.3 USER VIEW OF PILOT NETWORK 

The panel discussed how the user views the network. Figure 12-1 shows some 
possibilities of the user's concept of the network services. Illustration 
(a) shows the user terminal connected to each local system with ADS 
invisible as a networking function. After discussing this arrangement, the 
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O USER TERMINAL 


O LOCAL SYSTEM OR 
LOCAL NETWORK 


Figure 12-1. User View of Network Services 



panel decided that it was probably not realistic; the user would probably 
not view the system that way. Representation (c) of the system is more in 
line with the long-term ADS picture. The users dial into a system called 
ADS with its data system and information extraction services. However, in 
the short term with the three pilots that we now have, that view is not 
realistic. The resulting user view of the network systems is shown in view 
(b). The user is aware of the ADS network added on the local system. Part 
of the user interface will be influenced by the network and part will not. 
^his view does take into account the actual network as it is likely to 
exist with the three pilots. 

In the short and intermediate term, users will connect to their "home" 
system and obtain network services through it. Network services will be 
visible to the user as separate from local system services. The interface 
may have to be different, except where TAE or a similar "transportable 
executive" is used for both. 

12.4 REQUIREMENTS FOR STANDARDS AND GUIDELINES 

There is a need for a continuing oversight body for maintaining and 
monitoring standards and guidelines. Standards should be self-enforcing; 
guidelines not necessarily so — they must be monitored to see compliance. 
There is a need for maintenance, and there should be some way to get 
feedback as to whether guideines are of any use or validity. 

12.4*1 Dial-up Procedures 

Figure 12-2 (a) shows that for a near-term view the network should not be 
considered as^^transparent. This would reflect GSFC users connected to the 
"GSFC network" and JPL users connected to the "JPL network"; this is not 
realistic in the near term. Users connected to each local system and the 
user view that each one of these local systems can connect in some way with 
any other, independent of location, as shown in (b), is more realistic. 

With the exception of such things as retrieval time and cost, it would not 
be apparent to the user if the connection were by local or long-haul 
network. Since users will connect to local systems, no standard or 
guideline is needed. 

12 . 4.2 Terminals 

The basic network functions defined in Table 12-1 don't need more than 
basic . (300 baud hardcopy) ASCII capability, but menu support may need such 
additional functions as screen clear, cursor addressing, scrolling, and a 
higher data rate. A guideline or standard based on what is needed to 
correctly support a Menu System (processor) in a user-friendly way is 
required. This implies a minimum of 1200 baud "dumb" CRT; 300 baud 
hardcopy is marginally acceptable. 

12 . 4.3 Common Capabilities 

Figure 1 2-3 is the panel s model of the user' s view of the catalogs and 
directories. The panel developed this model as a basis for a standard user 
interface. This model shows the local catalog(s) as transparent to the 
user. The user would deal with the high-level directory, standardized over 
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TABLE 12-1 

PILOT NETWORK FUNCTIONAL REQUIREMENTS 


GROUP 1 - MANDATORY 


• COPY "FILE" 

• DISPLAY DIRECTORY CONTENTS 

• DIRECTORY ATTRIBUTE SEARCH 

• CREATE DIRECTORY ENTRY 

• MODIFY DIRECTORY ENTRY (SOME ATTRIBUTES PROTECTED) 

• DELETE DIRECTORY ENTRY (AND CORRESPONDING DATA SET) 

• HELP 

• DISPLAY STATUS OF ANY OF THE ABOVE PROCESSES (IF APPRO- 
PRIATE ) 


PRIORITY GROUP 2 


• DISPLAY NETWORK STATUS/STATISTICS 

• SEND MESSAGE 

- TO LOGGED-ON USER 

- TO MAILBOX 


PRIORITY GROUP 3 


• PROVIDE SAMPLE DATA SETS 

- PRE-CANNED 

- FIRST N POINTS, RECORDS,... 

[- SAMPLED, AVERAGED,...] 

• PROVIDE ESTIMATES OF "COST" BEFORE EXECUTING A NETWORK 
OPERATION 

- DATA SET SIZE 

- ELAPSED TIME 

- COST (IF USED) 

• BROWSE 

• SEND MESSAGE TO BILLBOARD 

GROUP 4 * 

• NETWORK LOG ON /OFF 

- TRANSPARENT TO USER 

• establish/remove/modify USER AUTHORIZATION 

- NOT AVAILABLE TO USER 

• run/cancel explicit process 

- FUNCTION NOT NEEDED IN SHORT TERM 

• SEND BROADCAST MESSAGE 

- NOT AVAILABLE TO USER 

• DIAL-UP, LOCAL SYSTEM LOG ON/OFF 

- CANNOT STANDARDIZE 


*Functions may be required, but user interface standards/ 
guidelines are not required. 
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Figure 1 


the network. The linkage between the directory and the actual data set 
would be invisible. If the users have to see a local catalog or directory, 
that interface could not be standardized. ADS should seek to standardize 
the user's view of the interface to a high-level directory. 

The panel prioritized the functional requirements for the pilot network for 
which standard user interfaces would be needed. These requirements are 
grouped in Table 1 2-1 based not necessarily on functional importance but on 
the need for standard user interface. Clarification is needed for 
functional requirements shown to accurately reflect the directory/catalog 
concept and criteria established by Panel A. This is an item for future 
work. 

The panel anticipates that the user will want sample data sets — the larger 
the data set, the greater the need for a variety of different samples. The 
user may want to look at smaller data sets quickly prior to operating on 
larger data sets. (This is a strong requirement in the Oceans Pilot.) The 
value of this function depends on the typical size of the data set with 
which one is dealing. The user should be aware that sample data sets exist 
and should be aware of how to get them even if the directory-pointing 
mechanism is transparent. This requirement is shown in Group 3 to indicate 
that it is a longer term effort. 

12.4.4 Language Interfaces 

It is hoped that TAE and RSS will develop into the defacto standard for the 
three pilots. This may be modified by current pilot methodologies and 
external standards. 

12.4.5 User Consultant 

There should be a human user consultant available to be used for 
human- to-human assistance. Guidelines are needed for a user consultant. 

The scope of the guidelines includes who, how many, organization (local 
system, local network, ADS network), functions, and expertise. 

12.5 RECOMMENDATIONS FOR FUTURE WORK 

12.5.1 It is recommended that there be a continued panel existence more or 
less as a design review committee to influence and monitor TAE, RSS, and 
allied efforts from the point of view of user interface, with members 
represented from: 

o Pilots 

o ADS Standards Office 
o NASA Headquarters 
o Other TAE users 
0 TAE developers 
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There is a need to clarify TAE maintenance and control policy , 
organization, and authority of the review committee. The charter of the 
TAE/RSS review committee should be: 

0 To test and evaluate the software to be used; 

0 To recommend changes to be done; 

0 To review documentation. 

This will consume resources and time; a minimum estimate is 1 /4 person per 
pilot. It should not be necessary for this committee to meet frequently. 
Most of its work can be done by mail, with occasional teleconferences. 

12.5*2 Liaison should be maintained with CODASYL and ANSI to monitor work 
in command languages, using mechanisms available to influence both in the 
public sector by: 

0 Including ADS standards people and TAE developers on mailing 
lists; 

o Contacting Capt. Bruce Hogman and William LaPlant (Pentagon, DOD 
software standards) who might provide current status of ANSI/X3H1 
and CODASYL COSCL to D.C. area people. 

12.5*3 There should be a study to understand user interface procedures of 
technology transfer organizations, e.g* , Eastern Regional Remote Sensing 
Applications Center (ERRSAC) , etc* for both human training and computer 
methodologies. 

12.6 ADDITIONAL COMMENTS 

a. Critique of MITRE methodologies must be done by each pilot, not in 
this panel. 

b. In Priority Group 3 (Table 12-l), the functions represented in the 
first two bullets may be interpreted by others as ADS value-added 
functions and therefore inappropriate for an early ADS, or even an 
interim ADS. 

c. The CSC-distributed dociment available at the workshop seems to 
imply from the start an attempt at an ADS central facility. This 
would be a policy decision, and is not yet firm. 

d. There is at least a partial impression that the viewpoint in 
Figure 12-1 of the "User View" and our definition of "user" does 
not agree with the Panel D viewpoint. This must be reconciled 
before candidate standards can be written or tested. 
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12.7 PANEL B PRESENTATION DISCUSSION 

Pat Gary asked if Panel B's concept of the directory is consistent with 
that of Panel A's description, and if there exists a single standardized 
directory at the top. 

Jim Brown answered that he didn' t say that there was a single one. In the 
long term it is desirable that the user view of ADS is a single, top-level 
directory that is global. It isn't known if it will be practical in the 
future, but it is not now. The panel didn't discuss how to deal with it, 
but it is something to work on with regard to interconnecting these pilots. 
He expects that the likely case for the top-level directories is that they 
will be physically distributed but will be logically centralized. 

Pat Gary commented that when the user realizes that the data set he is 
seeking is not to be found locally, then he is going to make further 
queries through that user interface at a remote site. Pat asked if that 
interface will vary depending on location. Is it acceptable or desirable 
on the short term that the user have a specific, non-standard interface for 
each local catalog? 

Jim answered that it is desirable that the user not even be aware that 
there is a local catalog. Given current implementations, that probably is 
not practical in the short term. The Ocean Pilot is consistent with this 
model - the local catalog is invisible to the user, but it isn't known if 
it is true for the other pilots. For the panel's purpose, they assumed 
that is was not true in general and that there are some local catalogs. 

Even though it's desirable to standardize them, in the short term they do 
not hope to standardize local detailed interfaces. It is desirable but not 
practical. 

Someone from the audience asked what the difference is between the 
broadcast message (Group 4 - Table 12-1 ) and the billboard 
"teleconferencing" (Group 3). 

Jim answered that broadcast is something that you get on your terminal 
whether or not you want it, and billboard is read-at-discretion. 

Another member of the audience commented on User Commands, Priority Group 
1 , that maintenance of the directory would be done off line and not by 
users, and that there is no command for interfacing with lower level 
catalogs. 

Jim answered that the assumption for directory maintenance is that, as in 
RSS, a file copy operation would create a user-owned file and corresponding 
directory entry. If this is the case, then the user needs directory 
manipulation facilities. This is a policy issue that needs to be worked. 
The three pilots agree substantially on what users are allowed to modify. 
Commands for interfacing with lower level catalogs could not be 
standardized due to lack of information regarding local catalogs; prefer a 
transport interface. 
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Barbara Walton commented that there is a question of long and short term 
and transparency rather than functionality. Panel A didn't see the link as 
transparent in the short term; they had a problem with that. Panel B's 
view .was that the local user saw the directory and not the local catalog; 
in Panel A they saw that as desirable in the long term but not possible in 
the short term. 

There was agreement with Barbara's comment. 

Ed Schlosser asked if the panel had determined if user interface is 
conversational and stated that conversational interaction has some 
problems. 

Jim answered that it is implicit that the interface is basically 
interactive and that it is explicit that no operation will tie up the 
terminal. The implication is that status posting is required for any 
process which cannot be completed within a few seconds. 

Dave Stowell commented regarding user requirements that "human/human 
consultancy" should be flagged as existing. It is an important item. 
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13.0 PANEL C REPORT; STANDARDS NEEDED FOR THE USE OF ISO OPEN SYSTEMS 
INTERCONNECTION - BASIC REFERENCE MODET 

15.1 INTRODUCTION 

Panel C of the Application Data Service (ADS) Data Systems Standards 
Workshop met to discuss the recently developed International Standards 
Organization (iSO) Open System Interconnection (OSl) Reference Model (l) 
and to explore its relevance to interconnecting the ADS pilots for data 
sharing. All three pilot programs were represented on this panel as well 
as participants with broadly based experience in related fields. Given the 
diverse background of the participants and the limited time available for 
discussion, the panel was unable to explore the many detailed interface 
considerations needed to thoroughly analyze the relevance of the OSI 
Reference Model to the ADS. Nevertheless, the panel concentrated its 
efforts by performing a top-level mapping between the conjectured ADS 
requirements and the identified layers within the OSI Reference Model. A 
number of issues of a more detailed nature were identified for further 
study. Panel C attendees are as follows: 

Richard Berman, CSC Edward Greene, GSFC, Chairman 

Joseph L. Bishop, NASA HQ. Adrian J. Hooke, JPL 

William Bisignani, MITRE John Johnson, JPL 

Albert Bowers, MITRE John Kiebler, NASA HQ 

Gary Brammer, LARS James Moulton, NBS 

Paul Clemens, MITRE William Poland, Jr., GSFC 

Richard desJardins, CTA A1 Skopetz, GSFC 

David Freeman, LARS Robert Stephens, NASA HQ 

J. Patrick Gary, GSFC Phil Yu, GSFC 
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15.2 OVERVIEW OF OSI REFERENCE MODEL 

The OSI Reference Model represents a conceptual architecture for 
telecommunication interconnections which consists of a hierarchical 
structure composed of seven layers. The principal functions performed or 
services rendered by each layer is shown in Table 15-1. Figure 15-1 
illustrates the actual data flow (dotted line) and the virtual data flow 
(solid lines) between two application processes running in systems that 
are, in general, distinct and geographically separated. At each level, 
there is an illusion of a direct peer-to-peer protocol connecting the two 
systems. However, in reality, the actual control and data communication is 
between adjacent layers. The N-th layer protocol performs identifiable 
services to the (N+1 )-st layer and, in turn, requests services from the 
(N-1 )-st layer. If the two systems are distinct, then the actual signal 
communication is performed at the Physical Layer (layer l). The interface 
to the applications process is at the Applications Layer (layer 7). 


Table 15-1 

OSI Reference Model Layers 


Layer 

Name 

Description 

1 

Physical 

Physical signal interconnect from 
point-to-point 

2 

Link Control 

Data interconnect from 
point-to-point 

5 

Network 

End-to-End data interconnect 
(Source DTE to Destination DTE) 

4 

Transport 

Host-to-Host data transfer 

5 

Session 

Dialogue synchronization between 
hosts 

6 

Presentation 

Data conversion services 

7 

Application 

Interface to application processes 
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Figure 13-1. Actual and Virtual Data Flow 



At the lowest three layers, there are existing protocols that conform 


substantially 

are: 

with the OSI Reference Model. Some of the possible cho: 

Layer 

Name 

Examples 

1 

Physical 

EIA RS-232-C, RS-422-A, RS-423-A 
CCITT V.28, V.35 
MIL STD-1 88C 

2 

Data Link 

Binary Synchronous Communication 
(Bi-Sync) 

ADC CP, SDLC, HDLC 

3 

Network 

X.21 , X.22, X.25, X.75 


Beyond layer 3, there are no nonproprietary general-purpose protocols which 
have been extensively tested; however, this is a field of active research 
within both the U.S. and European communities. Draft standards have been 
issued by the National Bureau of Standards (NBS) for both a Transport Layer 
and a Session Layer protocol. It is anticipated that these draft standards 
may emerge as mandatory Federal Information Processing Standards (PIPS) 

(for U.S. government systems) after these protocols have been extensively 
reviewed and tested. Both IBM and Digital Equipment Corporation have 
telecommunications software (SNA and DECNET, respectively) that provides 
services at all layers for networking among compatible-computer systems. 

13.5 ADS REQUIREMENTS IDENTIFICATION 

In order to determine the relevance of the OSI Reference Model for 
addressing ADS requirements, the Panel considered a scenario representing a 
broad class of capabilities which were considered required to interconnect 
the pilots for data sharing. The interconnection protocols needed to 
support this scenario were then identified, and these protocols were then 
classified in terms of standard layers within the OSI Reference Model. 

The scenario consisted of a series of steps described in Table 13-2. In 
essence, an investigator utilizes a terminal to perform a search of a 
nonlocal data base, initiates the execution of a process resident oh a 
remote processor using the selected data- set as input data, copies the 
generated data set to a different processor where it is added to the data 
base, the corresponding directories and catalogs are updated, and an 
electronic mail notification of the new data set is given to selected 
colleagues. 
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Table 13-2 
Scenario 

Research user sits down at alphanumeric terminal and performs the following 
functions; 

1 . Attaches to local host 

2. Remote data base inquiry 

0 Accesses root of directory in local host 

o Linked to remote host for secondary directory services 

o Submit request for information about data of interest 

0 Receives data descriptors/pointer 

0 Iterates process to locate data set of interest 

3* Request remote processing of data set. Activate resource 
estimation/accounting function 

4. Copy generated data set to local or remote data base and add to 
catalog 

5* Notify colleagues of new data set by electronic mail 
6. Terminate link/logoff 


To support this scenario, the protocols listed in Table 13-3 are required. 
Items 1, 2, 5, and 9 are essential layer 5 functions, and the remaining 
items are combined layer 6 and layer 7 functions. Since nonlocal 
intercomputer communications is required by this scenario, layer 1, 2, 3> 
and 4 prptocols are required to support the higher layer protocols. 

Other capabilities discussed as appropriate for long-term ADS 
consideration, but beyond the scope of that needed to interconnect ADS 
pilots for data sharing included: 

r 

a. distributed data bases, 

b. multiprocessor application processing, and 

c. generalized word processing (interoperability among equipment from 
diverse manufacturers). Additional layer 5, 6, and 7 protocol 
services would be needed to support these functions. 
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Table 15-3 

Protocols Required to Support Scenario 

1 . Terminal support 
— Local 

— Dial-in through network* 

2. Automatic login/accounting to applications manager 

5. Catalog manager command/response interaction, data base inquiry 
and response (command language, data descriptors) 

4» Pile transfer 

5. Applications executive interaction (suspend/resume, etc.) 

6. Privacy/security services 

7. Message to operator/mailboxes 

8. JSC word processor access* 

9. Automatic log off 

*Additional near-term capability not directly derived from scenario 


15.4 NEAR-TERM TELECOMMUNICATION SUPPORT METHODOLOGY IN ADS PILOTS 

The Pilot Atmospheres Data System (PADS) at the Goddard Space Flight Center 
and the Earth Resources Pilot System (ERPS) at the Lyndon B. Johnson Space 
Center have developed and adapted telecommunications software to service 
the needs of their individual pilot demonstration. The computer system for 
the Oceanic Pilot System (OPS) at the Jet Propulsion Laboratory will be 
delivered this summer and is expected to utilize the DECNET software for 
intrapilot networking. Figure 15-2 shows the initial telecommunications 
software that is being implemented for each pilot. The classification of 
the software into OSI Reference Model layers is only approximate. 

15.5 INTEGRATED TELECOMMUNICATIONS CANDIDATE 

The following are three basic approaches which could be considered for an 
integrated ADS pilot network system: 

Approach 1 : modify the software of the near-term conf^iguration 

(Figure 15-2) to permit interpilot telecommunications. 

Approach 2: adopt a computer manufacturer sponsored 

telecommunications package such as SNA or DECNET, 

Approach 5: adopt existing and emerging national and international 

telecommunication standards to the greatest possible degree. 


60 


NEAR TERM CONFIGURATION 
LAYER PADS ERPS OPS 




RSCS 

(HASP) 


D 

E 

C 

N 

E 



2 




Figure 13-2. Near-Term Configuration 
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There are advantages and disadvantages associated with each of these 
approaches. 

Approach 1 offers the advantage of providing the potentially easiest means 
of transferring bits between two computers. With a minimum of effort, it 
is anticipated that software modifications could be made so that the raw 
bit streams representing data and control messages could be interchanged 
among the three pilots. However, it is not enough to reliably transfer a 
sequence of bits; we need to be able to exchange information. This is a 
great deal harder to do via approach 1 , since the command language 
structure and codes are not uniform among the three pilots. This lack of 
uniformity in command language structure and data structures is likely to 
result in a very awkward telecommunications capability. Either some very 
"kludgy" software would have to be written to translate between the native 
codes of the three pilots, or the user would have to employ different 
conventions and utilize different command languages, depending on the host 
computer to which the user was attached. Either alternative is considered 
very undesirable and the panel rejected this approach. 

Since two of the pilot systems (PADS and OPS) are oriented towards the DEC 
computers and the ERPS is oriented toward IBM or IBM lookalike computers, 
approach 2 considers the adoption of DECNET or SNA as the ADS 
telecommunications system. Both DECNET and SNA provide a rich variety of 
file transfer and data base services; however, they are parochially adapted 
to the hardware and software system supplied by the respective 
manufacturer. This is not to say that it is impossible to use the DECNET 
structure on a non-DEC system or the SNA structure on a non-IBM system; 
however, the non-native equipment would tend to experience inferior 
performance if it could not exactly emulate the system for which the 
proprietary software was designed. Hence, the adoption of a proprietary 
telecommunication system would tend to give a specific manufacturer a 
significant advantage over its competition. For this reason, the panel 
chooses not to recommend approach 2. 

The third approach involves the tentative acceptance of protocols which are 
so new and unproven that they exist only as draft standards. The NBS has 
issued specifications (2,3) of a layer 4 (Transport) and layer 5 (Session) 
protocol which appear to be the leading contenders for standard protocols 
at these levels. It is anticipated that, after an extensive review 
process, these protocols will become FIPS and be required for future 
telecommunications support on U.S. Government systems. The proposed draft 
layer 4 protocol is intended to provide the proper interface to the major 
existing layer 3 protocol such as X.25 and X.21 . 

Above layer 5, the processing functions become so diverse that there 
appears little hope for the development of a single standard protocol at 
layer 6 or layer 7 in the near future. Instead, it is likely that a series 
of standard modules will be developed which perform certain well-defined 
functions at layers 6/7 and which interface to the standard layer 5 
protocol. One such module, the NBS File Transfer Protocol, is scheduled to 
be released in draft form in early 1982. Other standard modules will 
undoubtedly be developed but probably not on a timeframe that will benefit 
the ADS. Approach 3 involves making a tentative commitment to use the NBS 
proposed layer 4 and 5 protocols and the File Transfer Protocol (layer 6/7) 
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when available. Other essential layer 6/7 functions needed by the ADS 
would have to be specially developed for the ADS and should interface to 
the standard layer 5 protocol. 

The panel did not have the time to assess the adequacy of the NBS draft 
protocols at layers 4 and 5« Nevertheless, after rejecting approach 1 and 
2, the consensus of the panel was that approach 5 deserves cautious 
support. While this approach is likely to be the most frustrating and 
difficult on a short-term basis, it is the only approach which offers a 
potentially viable solution for the effective networking among 
non-homogeneous systems. Figure 13-3 illustrates some of the protocols 
that are needed for the candidate ADS configuration and their relationship 
to the OSI Reference Model. 

13.6 CONCLUSIONS 

Considering the diversity of experience among Panel C attendees, the 
breadth of the topic to examine, and the very limited time available for 
deliberation and discussion, the panel could only provide tentative advice 
regarding the choice of protocols for an integrated ADS network 
demonstration. The recommended approach discussed in the preceding section 
is fraught with many uncertainties. Nevertheless, it is the consensus of 
the panel that the OSI Reference Model represents an orderly architecture 
for the ADS networking planning and that the standard protocols being 
developed by the NBS offer the best available implementation approach. 

13.7 RECOMMENDATIONS 

The issues considered by this panel cannot be satisfactorily resolved by a 
diverse group during a 2-day workshop. It is the panel's recommendation 
that a working group be established to continue to investigate these issues 
and to track the progress toward a successful interconnection of ADS 
pilots. Listed below are some specific topics for the Working Group 
investigations : 

13 . 7.1 Review currently identified requirements versus other panels for 
consistency and completeness. 

Panel C identified the need for protocols to support the functions 
identified in Table 13-3. These requirements need be compared with the 
requirements identified by other panels for consistency and completeness. 
The intent is to direct attention to provide or plan protocols to meet any 
extra requirements. 

13 . 7.2 Develop functional specification of input parameters for each 
application to be supported (input to layer 7). 

After the requirements of an ADS network have been identified, each 
application must be isolated, and a functional or performance specification 
must be described. Once this information is known, the functional 
specification of the application can be broken down into subfunctional 
groups that will describe the input parameters. These parameters are the 
user interface between the application process and the protocol of the 
application layer in the ISO model. The specification of the input 
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Figure 13-3. Integrated Configuration Candidate 
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parameter functions can then be used to develop design specifications for 
each parameter. 

13.7.3 Develop design specifications of output strings/packets/message 
blocks for each application to be supported (output "from 6 to 5 "). 

Pilot implementation of the identified application functions (e.g., remote 
catalog manager request/response, file transfer, process initiation, and 
user message exchange) requires detailed specification of the strings, 
packets, and/or message blocks which will be output from one host system's 
layer 6 protocol function for input to another host. Currently, with the 
exception of file transfer, no federal standards exist to guide the design 
effort needed by the ADS pilot system to provide mutually compatible 
services for these functions. 

Detailed descriptions of the information content, format, and layout of the 
message blocks to be exchanged and the encode/decode processing to be 
applied to the message blocks must be specified. 

13*7.4 Evaluate existing layer 4 and 5 protocols, including the NBS 
proposed standard, and recommend selection for pilot system and future ADS 
use. 

The purpose of this effort is to evaluate and recommend approach for the 
implementation of the transport and session layers of the OSI. This will 
be accomplished by a review of existing pilot system implementations, 
proposed standards (e.g., NBS) , and other existing protocols (e.g., SNA). 
Additional points of consideration include: 

a. a cost analysis of "build versus buy," 

b. that portion of the pilot systems' charter which effects the 
exploration of new technologies, 

c. the possible addition of new nodes to the ADS network, 

d. existing hardware and software in the centers involved, and 

e. facility with which a near-term implementation may evolve into a 
longer term solution. 

The output of this task should include the following recommendations: 

a. technologies and methods for a near-term implementation, and 

b. longer term analyses and studies pointing toward a solution for 
future ADS system. 

13*7.5 Perform a requirements analysis for the ADS at the combined layers 1 - 3 . 

The service requirements for the interconnection of the pilots and for 
future ADS capabilities will determine which services are best suited 
(packet switched, dedicated line, other). 
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0 No new standards required for these layers; ADS just has to select 
those it needs. 

o Traffic between nodes will determine service required. 

0 X .25 not cost-effective, under current tariff structure, for use 

of more than 2 hours/ day — dedicated line would be cheaper. 

0 Satellite communication links have to be considered for high-data 
rates . 

0 The reliance on local area networks at the member nodes has to be 
considered for impact on the ADS network. 

13.7.6 Specify core requirements expected for each protocol layer for 
pilots and future ADS use. 

In general, standard protocols provide a large number of options and 
services, not all of which are germane to a specific application. Because 
of this, most implementations of protocols consist of a subset of the full 
capability defined by the standard. Incompatibilities arise when different 
user systems adopt different subsets of the standards, and the logical 
intersection of the various subsets are insufficient to provide the 
necessary services. This task is concerned with developing guidelines for 
each applicable protocol which identify the core functions and capabilities 
expected from each user implementation to support the future ADS 
interconnection uses. 

13.8 PANEL C PRESENTATION DISCUSSION 

Tom Bums asked if the panel had a chance to look at tradeoffs between 
packet switching and datagram connection. 

Ed Greene replied that it might be approved for both but that it is an 
economics decision and should go into the "further-work category." 

Someone from the audience stated that a phone call or telegram is a 
connectionless concept in the model and asked if there is a requirement. 

Ed answered that it is not considered in this model; it is an anticipated 
interactive requirement. 
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U.O PANEL D REPORT; STANDARDS NEEDED TO INTERCONNECT ADS PILOTS FOR DATA 
SHARING IN DATA FORMATS AND DESCRIPTIONS ~ 


14.1 BACKGROUND 

At this point in the development of information and communications systems 
technology in general, and the growing multitude of space- related data 
bases in particular, it is appropriate that data interchange between 
distributed, non-af filiated (foreign) data bases be pursued by NASA in 
order to gain experience with such systems and nurture a future user 
community. The ADS Standards activity has thus been formed to provide for 
the creation of data interchange rules and protocols, and to serve as a 
"brass board" for the generation of long term techniques and standards for 
this far reaching technology. 

The universal need for access to CATALOG data from non-affiliated data 
bases is repeatedly expressed in ADS workshop reports. This reflects a 
real user requirement to be able to interrogate various data bases to see 
what products are archived. The demand for networked access to 
multi-source data products from multiple data bases is less clearly 
defined; this is probably a result of justifiable caution within the user 
community, who are wary of grandiose systems which promise wonderful things 
but do not deliver. The challenge of the ADS pilots is therefore to 
demonstrate that such systems can in fact be made to work, and to develop 
the framework for future operational systems. 

The charter of the Data Formats and Descriptions Panel was to identify the 
scope of data specification standards that need to be adopted in order to 
facilitate the interchange of information between the archival pilots 
nodes. A list of panel participants follows. 

Thomas Burns, MITRE 

Dennis Fife, NBS 

Edward Greenberg, JPL, Chairman 

Edgar M. Greville, CSC 

Larry He rath, GSFC 

Merv MacMedan, JPL 

Ed Schlosser, Lockheed 

Valerie L. Thomas, GSFC 
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U .2 SUfflARY OF PANEL DISCUSSIONS 

It was the consensus of the panel that data exchange standards should be 
developed to he of general future utility, though the near-term activity 
should he constrained to focus on the problems of interconnecting the ADS 
Pilots. The intent is to Use the three pilot nodes to evaluate the 
generalized applications of the ADS. The panel agreed that the following 
considerations were important when standards are designed: 

a. DBMS catalogs should be accessible and understandable to remote 
users (both humans and applications processors). 

b. Formatting conventions should be constrained to have minimal 
impact on existing archival data sets or on currently-generating data 
sources (e.g., Landsat) , though they should be designed to provide guidance 
for future DBMS developments. 

c. Archival data records and their data descriptions should be 
available in globally-identifiable, machine readable and interpretable form 
so that users can automatically interact with variable, non-af filiated data 
sets from remote DBMS nodes. The format of the records and descriptions 
should be machine and medium independent. 

d. Terminology must be scrupulously defined. Definitions, words, 
units and general vocabulary should be standardized. Everyone should have 
the same understanding of the same word or definition. 

e. Each DBMS node should have the option to optimize its data formats 
(at the discretion of the local authority) as long as minimal constraints 
imposed by global standards are met. 

14.3 PANEL RECOMMENDATIONS 

The specific recommendations that this panel extends are as follows: 

14.5.1 The ADS should establish a standard vocabulary of terms, units, 
descriptions, and definitions. This must be accomplished in the immediate 
future. Although the early versions of the vocabulary need not be 
complete, they must provide the foundation for enabling the definitions . of 
requirements and specifications to proceed. 

14.5.2 The ADS should provide a machine- readable standard mechanism, which 
is medium and machine independent, for describing data content, structures, 
numeric representations, and character codes. It is vital that these 
definition mechanisms should be adopted as soon as possible in order to 
facilitate the pilot interchange of data, and in order to provide guidance 
for the future data sets which will be generated in coming years. The 
mechanisms adopted MUST be adequately defined, with user guides and 
examples, and MUST have expansion capabilities. 
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14«5«3 The ADS should establish a set of preferred numeric 
representations, a preferred character code, preferred units, and preferred 
descriptions. The ADS vocabulary should recognize and define ALL of the 
used or usable codes, units, and descriptions which currently exist within 
the pilots, but a subset of these MUST be identified as the preferred set. 
It is highly desirable that each pilot node should perform conversions of 
those existing data elements that are not in the preferred form, thus 
reducing the number of conversions which must be performed by each user 
processor. 

14.5*4 The consensus of the panel was that the view of each of the panel 
participants was limited. The panel members felt that it is critical that 
the ADS should establish a permanent, dedicated team to pursue these 
recommendations further. While it is impractical for the panel to 
recommend detailed specific items for the team, we propose that the 
following near-term outline be pursued; 

a. The permanent team should begin by analyzing the data formats, 
codes and representations used in existing pilots. 

b. The team should analyze existing and proposed data interchange 
standards. 

c. The team should adopt or create Strawman standards for review by 
data base administrators for each pilot and associated NASA data base. 

d. The team should establish an ADS data standards administration 
function to approve, disseminate, maintain and provide visibility for these 
standards. 

e. The team should provide top-level coordination for the development 
of catalogs, in order to: 

i) Provide to the catalog designers the mechanisms for describing 
data sets. 

ii) Evaluate the adequacy of the catalog structures to enable 
users to access and select data. 


FOOTNOTE: 

Owing to the shortness of time allowed, the MITRE presentation on pilot 
standards methodologies was not critiqued by the panel. We would however 
like to commend the MITRE assessment of the standards that need to be 
developed to support Pilot Data interchange: this presentation showed 

substantial technical insight. 

14.4 PANEL D PRESENTATION DISCUSSION 

Pat Gary asked if the panel hopes for short- or long-term activity. 

Ed Greenberg answered that the panel didn't address time; they addressed 
urgency. Data must be described in a standard way and it must be done now. 
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Tom Burns commented that the standard visibility requirement (see 14*5»4) 
must be emphasized. 

Ed Greenberg said that we need electronic access to what people are doing., 

Pat Gary stated that it would be a good thing if we built an on-line data 
base. 

John Kiebler asked where specific formats went which were there at the 
start but are not there now. 

Ed Greenberg replied that the panel did not have all of the details of the 
other formats. 


I 
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15*0 WORKSHOP SUMMARY - Barbara Walton, GSFC 

The workshop unanimously recommended the development of a standard for data 
product preparation to ensure quality data sets. The recommendation 
prepared by Richard desJardins, as given in Table 15-1, was adopted. 

There is a lot of work to be done in the standards area. The panels' 
detailed requirements and the recommendations for future work are vital for 
the ADS program. Many of the workshop attendees will be called upon in the 
future for participation in working groups. 

A document with the proceedings of the workshop, including the 
participants' addresses, will be distributed to all of the attendees of the 
workshop. 

15.1 WORKSHOP SUMMARY DISCUSSION 

Ed Greene agreed with Richard desJardins' recommendation to OSTA and 
commented that it presumes quite a sophisticated data configuration 
management, under strict control. 

Richard desJardins said that it might be considered a goal, an ideal, but 
it may never be implemented. 

Jim Brown commented that it has been done (for instance, with the Seasat 
Altimeter) . 


^^•0 ACTION ITEMS - John Kiebler, NASA Headquarters 

Draft panel reports are due to Barbara Walton in two weeks with a final 
version due in one month. 

The panels didn' t do much critiquing of the MITRE representation of the ADS 
pilot methodologies, which was one of the intents of the workshop, so it is 
up to the pilots to review the methodologies and report in a few weeks' 
time. 

A meeting of the Steering Group will be held in room 206 at 2 p.m., to 
which panel chairmen are invited. 

John thanked the participants and said that he thought the workshop had 
proven productive. 
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Table 15-1 

Recommendation to OSTA on a Data Product Preparation Standard 


Users of ADS may acquire some data only to find that crucial aspects of the 
data are unknown or missing, e.g. , the position and time of data taking, 
the processing steps performed, the calibration curves used. While these 
aspects are of little consequence for systems interconnection protocols, 
they may be crucial for effective utilization of the data. 

Therefore OSTA should develop a standard or guideline for Data Product 
Preparation. The intent of this standard would be to provide to data 
preparation personnel a checklist to assure the quality of the data as 
defined by the 1979 OSTA Data Systems Planning Workshop. The term 
"quality" was used at that workshop to signify the quality of the data 
preparation process rather than the apriori intrinsic goodness of the 
sensor data. 

The scope of the standard would include; 

0 data preparation practices (e.g., recommended quality assurance 
practices, scientific data validation techniques) 

0 data labeling, and annotation (e.g., source, indications of gaps, 
comments) 

0 ancillary data (e.g., position, time, solar aspect) 

0 "pedigree" of the data (e.g., calibrations performed, noise 
removal technique used, algorithm applied) 

0 pointers of references (e.g., name and address of preparer, 

identification of data control documentation, reference data and 
software used including version numbers and algorithms) 
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Glossary of Terms 


ADCCP 

ADS 

ANSI 


Advanced Data Communications Control Procedure 

Applications Data Service 

American National Standards Institute 


CCT Computer-Compatible Tape 

CODASYL Conference on Data Systems Languages 

COSCL Common Operating System Command Language 

CMS Command Management System 


DBMS 

DDCMP 

DEC 

DOD 


Data Base Management System 

Digital Data Communications Message Protocol 

Digital Equipment Corporation 

Department of Defense 


ERPS 

ERRSAC 


Earth Resources Pilot System 

Eastern Regional Remote Sensing Applications Center 


FIPS 


Federal Information Processing Standards 


GSFC Goddard Space Flight Center 

IDBMS Integrated Data Base Management System 

IPS Information Processing System 

ISO International Standards Organization 


JPL 

JSC 


Jet Propulsion Laboratory 
Johnson Space Center 


NASA 

NBS 

NEEDS 

NOAA 

NTIA 


National Aeronautics and Space Administration 
National Bureau of Standards 
NASA End-to-End Data System 

National Oceanic and Atmospheric Administration 
National Telecommunication Information Administration 


OAST 

OPS 

OSI 

OSTA 


Office of Advanced Space Technology 

Oceanic Pilot System 

Open System Interconnection 

Office of Space and Terrestrial Applications 


PADS Pilot Atmospheres Data System 

PCDBMS Pilot Climate Data Base Management System 


R&D 

R&T 

RSCS 

RSS 

RTOP 


Research and Development 
Research and Technology 

Remote Spooling and Communications Service 
Remote Services Subsystem 

Research and Technology Objectives and Plans 
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S&G 

SFDU 

SNA 

SNAP 

TAE 

TDMA 

uses 

VAS 

VISSR 


Standards and Guidelines 

Standard Format Data Unit 

Systems Network Architecture 

System of Networked Applications Processors 

Transportable Applications Executive 
Time Division Multiple Access 

United States Geological Survey 

VISSR Atmospheric Sounder 

Visible Infrared Spin Scan Radiometer 
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APPENDIX A 


OSTA/ADS DATA SYSTEMS STANDARDS AND GUIDELINES DEVELOPMENT PROGRAM 
OVERVIEW OF THE CURRENT MITRE EFFORT 




Terry Kuch 
Rick Sakamoto 
The mitre Corporation 
McLean^ Virginia 


OSTA/ADS Data Systems 
Standards Workshop 
May 11 . 1981 



A- 2 


The OSTA/ADS Data Systems Standards and Guidelines Development Program is a 

COLLABORATIVE ACTIVITY. ThIS WORKSHOP PROVIDES THE OPPORTUNITY FOR ENHANCE- 
MENT OF ADS Standards and Guidelines through interaction with workshop 

PARTICIPANTS. 


Purpose Of This Presentation 


0 Present AN overview of the current effort 

0 Present a terminology and conceptualization of ADS for standards development 

PURPOSES 

0 Provide a context for the next two presentations 

- User requirements 

- Pilot methodologies 
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Outline Of Briefing 

0 Overview of current MITRE activities 
0 ADS Terminology 

0 ADS AS A DISTRIBUTED SYSTEM 
0 A FUNCTIONAL CLASSIFICATION OF ADS FEATURES 
0 A STANDARDS EVALUATION PROCESS FOR ADS 




MITRE ACTIVITIES: OVERVIEW 


1. Develop NASA-defined approach to OSTA/ADS data systems standards and 

GUIDELINES. 

2. Extend knowledge of data systems standards and guidelines organizations 

AND PROCESSES. 

3. Determine ADS members' requirements for standards and guidelines. l Following 

J PRESENTATIONS 

Survey and analyze methodologies of pilots. 

5. Survey existing data systems standards and guidelines. 

6. Compile a preliminary candidate set of OSTA/ADS standards and guidelines. 

7. Develop OSTA/ADS standards and guidelines evaluation process and criteria. 

8. Evaluate preliminary candidate standards and guidelines. 

9. Develop candidate standards and guidelines report. 

Major products: 

. MITRE Survey report MTR-81W5 (March 1981) 

. ADS Candidate Standards and Guidelines Report (August 1981) 
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MITRE ACTIVITIES: 1 


Develop NASA-Defined Approach to OSTA/ADS data 

SYSTEMS STANDARDS & GUIDELINES. 

0 Examine NASA and contractor documentation. 

0 Discuss ADS concepts with GSFC and contractor personnel. 
0 Establish consistent use of terms. 

0 Develop logical view of ADS for a standards development 

EFFORT. 

0 Develop OSTA/ADS functional classification scheme. 



A- 6 


TERMINOLOGY FOR THE ADS STANDARDS PROGRAM 


0 STANDARD 
0 GUIDELINE 
0 METHODOLOGY 
0 DISCIPLINE USER 
0 MEMBER 


0 


CENTRAL SYSTEM FUNCTION 



Administratively compelling 
(required at some admin- 
istrative level) 

Advisory 

Informational 

Exhaustive (complete within 
its scope) 

Exhaustive or selective, 
as required 

Selective 

Detailed 

Not necessarily detailed; 
may be used to set bound- 
aries within which stand- 
ards may be defined 

Detailed; based on actual 
implementation 

Adopted formally by key 
organizations 

Agreeable to key organ- 
izations, not necessar- 
ily adopted formally 

May be unique to one or 
a few organizations 

Broad scope of appli- 
cation to many systems 
and organizations 

Broad scope of applica- 
tion 

Limited scope of appli- 
cation 

Product-oriented 

Activity-oriented 

Product-oriented or 
outcome-oriented 

Compatible with other 
standards and guidelines 

Compatible with other 
standards and guidelines 

Not necessarily compat- 
ible with any standard, 
guideline, or other 
methodology 

Fully developed and stable, 
subject to evolution 

Less fully developed 

Not necessarily fully 
developed 

Addressed to technical staff 
or to technical project man- 
agement or to both 

Addressed to technical 
project management or 
to program management 
or to both 

Addressed to working- 
level technical staff 
























Discipline 



P* System 
Functions 


Physical Connection 
Logical Connection 
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Discipline users are scientists who use an ADS network 

MEMBER FACILITY IN THEIR RESEARCH. 

Members are facilities which participate in ADS. Each 

MEMBER PROVIDES A SERVICE TO DISCIPLINE USERS. A 
MEMBER FACILITY MAY OPERATE INDEPENDENTLY OF ADS AS WELL 
AS BEING PART OF ADS. 

ADS CENTRAL SYSTEM FUNCTIONS ENCOMPASS TECHNICAL SERVICES 
TO MEMBERS : 

0 Data communication 
0 Cataloging 

0 Administrative services (such as resource accounting) 
0 User assistance 

0 Value-added services (such as data integration). 
Central system functions may be performed by one or more 

MEMBERS OR DISTRIBUTED OVER THE NETWORK. 
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Resource Accounting, Reporting. Task Control, Quality Assurance. User Support 


(data Mt 
raaWanea) 


(proeaaa I 

raaWanca I 

(appHaattona 
ao(twaral) 


(computational 

tadtttyl 


OataTrana- 
lar Sorvlca 


Acquire data: 

generate: 

preprocess: 

edit: store: 

manage: 

maintain: 

update 


1-2 

Acquire appii* 

cations 

software: 

generate: 

store: manage: 

maintain: 

update 


1*3 

Acquire compu* 
talionai fac- 
ility: ntanage: 
maintain: 
modify 
configuration 


■ • • 
I 
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Insert 
information 
on data, 
processes, 
execution 
capabilities 
into locator, 
describe, document 


Communicate, deliver, transmit data and process 
from node to node or loMrom ADS and other networks 


2-4 

Identity 
a require- 
ment fora 
data product 


3-4 

identify types 
of data and 
general pro- 
cessing capa- 
bilities rteeded 
to satisfy the 
data product 
requirement 


3-5 

Query locator, 
interact: pro- 
vide response 
idaia. process- 
computational 
facility 
product! 


4-4a 

Negotiate data 
query; identify & 
locate specific 
data sets: request 


4-4b 

Negotiate process 
query: identify & 
locate specific 
algorithms or pro- 
grams; request 


4-4c 

Negotiate execu- 
tion query: ident- 
ity & locate spe- 
cific computation- 
al facilities: 
request 


I I T 
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Query locator: 
interact: 
provide 
response 


5-5 

Invoke (in- 
itiate access 
to) data. 
process(es). 
computational 
facility ties) 


6-1 

Access data: 
retrieve set 
or subset: 
initiate data 
transfer (if 
necessary) 


6-2 

Access 

process: 

retrieve 

applications 

software: 

initiate 

transfer (if 

necessary) 
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Manage aaia 

mamiaih 

update 


OPTIQNAL PATH 


Compute: process 
data: analyze: 
manipulate: re- 
format: summar- 
ize: extract: 
generate data 
product 


M 

Display data 
product: 
present; 
package 


9-4 

Make data 
products 
and packages 
available 


OPTIONAL PATHS 


9-5 

Insert 

information on 
data products 
into locator 


ACTIVITIES IN A DISTRIBUTED SYSTEM 


A-11 


















A-13 


A FUNCTIONAL CLASSIFICATION OF OSTA/ADS FEATURES 



Administrative Service 
Technical Service 
Data Transfer Service 


— Applications Data 

— Process (Applications Software) 

— Computational Facility 

— User-System Interface 




1.1 

Applications 

Data 


1 . 1.1 

Data Dafinition 

1 . 1 . 1.1 

Data Dictionary 

1 . 1 . 1.2 

Tima Definition 

1. 1.1.3 

Spatial Dallnitlon 

1.1. 1.4 

Ganaral Vocabulary 

1.1. 1.5 
Thesaurua 

1.1.2 

Data. Structure and Data Code 

1.1.3 

Data Content 

1.1.4 

Data Media 

1.1 .4.1 

Magnetic Tape 

1. 1.4.2 

Rotating Magnetic Media 

1.1. 4.3 

Optical Storage Media 

1. 1.4.4 
Microform 

1. 1.4.5 

Graphic Image 





ts 

Process 

(Applications 

Software) 


1.3 

Computational 

Facility 


1.4 

User-System 

Interface 


2.1 

Administrative 

Service 


2.2 

Technical 

Service 


2.3. 

Data 

Transfer 

Service 



NOTES: 1. Standards may apply to the nodes olthis hierarchy In one or more of three ways: 

• How to do It: 

• How fo describe it: 

• How louse it. 


2 . 1.1 

Operations & Maintenance 
2.1.2 

Resources, Accounting 
2.1.3 

Financial Functions 
2.’l.4 

Security, Access 

2.1.4.1 

Physical Security 

2.1 .4.2 

Data Security 

2.1 .4.3 

Access Security 

2.1.5 

Performance Evaluation 

2.1.6 

Management-Oriented 

Documentation 


2.2.1 


2.3.1. 

System Locators 


Data Communications 

2.2.1. 1 


Interfaces 

Ust of ADS Users 


1 • 

2.2.1. 2 


1 • 

Locator of Data Sets 


I • 

and Sources 


! 

2.2.1.3 


2.3.2 

Locator of Processes 


Data Communicatlona 

and Their Sources 


Protocol 

2.2.1.4 


2.3.2.1 

Locator of Computer 


Physical Layer 

Facilities 


2.3.2.2 

2.2.1 .5 


Data Link Layer 

Locator of System 


2.3.2.3 

Services 


Network Layer 



2.3.2.4 

2.2.2 


Transport Layer 

System Information 


2.3.2.S 

2.2.2.1 


Session Layer 

OlvUne 


2.3.2.6 

2.2.2.2 


Presentation Layer 

Off-Line 


2.3.2.7 



Application Layer 

2.2.3 



User-to-User 


2.3.3 

Message Service 


Media Transfer 


2. Eor each node of this hierarchy there may be kernel standards which apply to the system as a whole, and 
extension standards which apply to one or more, but not necessarily to all. ADS disciplines (user communities!. 


ADS HIERARCHICAL CLASSIFICATION SCHEME 
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MITRE ACTIVITIES: 2 


Extend Knowledge of Data Systems Standards and 
Guidelines Organizations and Processes. 

0 Identify standards-processing organizations. 

0 Collect standards and guidelines lists and 

CATALOGS^ AND COPIES OF STANDARDS AND GUIDELINES. 

0 Establish contacts with standards-processing 

ORGANIZATIONS (ANSL NBS^ ETC.). 

0 Identify existing procedures for evaluation of 

CANDIDATE STANDARDS. 
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MITRE ACTIVITIES; 3 


Determine ADS Members' Requirements for Data Systems Standards 
AND Guidelines 

0 Review previous work on ADS standards requirements. 

0 Visit three pilots^ collect information on their functional 

REQUIREMENTS PRACTICES^ METHODS^ FRAMEWORKS^ DOCUMENTS^ ETC . ^ 
ESPECIALLY IN THE AREAS OF DATA STRUCTURES^ DATA COMMUNICATIONS^ 
AND DATA IDENTIFICATION AND CATALOGING. 

0 Visit organizations and operations outside the three pilots 

WHICH MAY BECOME ADS MEMBERS^ OR MIGHT BE TYPICAL OF FUTURE 
ADS MEMBERS IN SOME WAY. COLLECT REQUIREMENTS INFORMATION AS 
ABOVE . 

0 Consider how these common functional requirements may be satisfied 

BY THE IDENTIFICATION AND DEVELOPMENT OF STANDARDS AND GUIDELINES. 

0 Report on standards and guidelines as solutions to problems 

ENCOUNTERED IN ADS. 



MITRE ACTIVITIES: A 


Survey and Analyze Methodologies of 
ADS Pilots. 

0 Visit three pilots^ collect detailed information 

ON PILOT METHODOLOGIES ESPECIALLY IN THE AREAS OF 
DATA STRUCTURES^ DATA COMMUNICATIONS^ AND DATA 
IDENTIFICATION AND CATALOGING. 

0 Consider which methodologies may be suitable for 
ADS-wide use. 


0 


Present findings. 



MITRE ACTIVITIES; 5 


Survey Existing Data Systems Standards and Guidelines 
0 Categorize^ list^ and index non-NASA standards and 

GUIDELINES WHICH MAY BE APPLICABLE TO ADS BASED ON 
A PRELIMINARY SCREEN TO ELIMINATE STANDARDS AND 
GUIDELINES WHICH ARE GROSSLY TECHNICALLY OR 
ADMINISTRATIVELY INAPPROPRIATE FOR ADS. 

0 Publish A survey document (MITRE MTR-81W5), 

0 Prepare and issue a supplement to the survey document 

INCORPORATING STANDARDS AND GUIDELINES FROM NASA 
PROGRAMS AND CENTERS^ AND UPDATING PREVIOUSLY PUBLISHED 
SURVEY INFORMATION. 



MITRE ACTIVITIES: 6 


Compile Preliminary Candidate Set of 
OSTA/ADS Data Systems Standards and 
Guidelines 

0 Compile the pilot methodologies and the 
APPLICABLE NASA AND NON-NASA STANDARDS 
AND GUIDELINES INTO A SET TO BE EVALUATED 
TO PRODUCE THE CANDIDATE ADS STANDARDS 
AND GUIDELINES DOCUMENT. 
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MITRE ACTIVITIES: 7 


Develop OSTA/ADS Data Systems Standards and 
Guidelines Evaluation Process and Criteria. 

0 Consider evaluation criteria used by standards- 

PROCESSING ORGANIZATIONS SUCH AS ANSI AND NBS. 

0 Consider ADS standards requirements identified 

IN A PREVIOUS TASK, 

0 Develop a process for evaluation of potential 
ADS STANDARDS AND GUIDELINES. 

0 Develop criteria for use in the process to 

EVALUATE POTENTIAL ADS STANDARDS AND GUIDELINES. 



A-23 


OST A/ADS Standards and Guidelines Evaluation 

Process 



OSTA/ADS Standards and Guidelines Evaluation 

Process (Continued) 














MITRE ACTIVITIES: 8 


Evaluate Preliminary Candidate 
Standards and Guidelines 

0 Pass the set of preliminary candidate 

STANDARDS AND GUIDELINES THROUGH THE 
EVALUATION PROCESS. 
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MITRE ACTIVITIES: 9 


Develop Candidate OSTA/ADS Data Systems 
Standards and Guidelines Report 

0 Organize the set of candidate OSTA/ 

ADS STANDARDS AND GUIDELINES; CATE- 
GORIZE; INDEX; PUT INTO AN OSTA/ADS 
STANDARD FORMAT. 

0 Prepare^ produce^ and publish the 
SET OF CANDIDATE OSTA/ADS DATA SYSTEMS 
STANDARDS AND GUIDELINES. 


APPENDIX B 


OSTA/ADS DATA SYSTEMS STANDARDS AND 
GUIDELINES DEVELOPMENT PROGRAM 


USER REQUIREMENTS 
FOR 

ADS STANDARDS AND GUIDELINES 


May 27. 1981 
BC-097 


Paul Clemens 

The mitre Corporation 

McLean. Virginia 



PURPOSE 


Present Results of a Survey of Representative 
ADS Network Members to Identify Requirements 
FOR ADS Standards and Guidelines 


GOAL 


Invite Comment and Discussion on 

- Functional Areas Requiring Standards 

- Adequacy of Identified Standards Requirements 

- Completeness of Survey 
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OUTLINE OF BRIEFING 

0 Task Overview 
0 General Findings 

0 Pilot Interconnection Functional Requirements 

0 Standards Required for Pilot Interconnection 
For Data Sharing 

0 ISO Open System Interconnection Reference 
Model Layer Characteristics 

0 Conclusions 
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TASK OVERVIEW - 2 


DEVELOPMENT OF STANDARDS REQUIREMENTS 






TASK OVERVIEW - 2 


0 Reviewed OSTA^ ADS^ and other Distributed Data Processing 
Documentation to determine those Functions Requiring Standards 
In a Distributed Environment such as ADS. 

Primary Sources Included: 

- Wallops Workshop Summaries (GSFC) 

- Standards Survey (MITRE) 

- DBMS Workshop Summaries (JPL) 

- PADS Methodologies Report (CSC) 

- ADS Generic Requirements (CSC) 

- Distributed Data Processing Standards Forecast (NAC) 

- PCDBMS User Requirements Study (OAO) 

- ADS Resources Pilot Program 5-YR Plan (JSC) 
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TASK OVERVIEW - 3 

0 Survey Meant to Elicit Concerns^ Interests^ Nature 
OF Programs in Addition to Standards Requirements^ 
Methodologies^ and Priorities 

0 Visited and Surveyed Pilot Projects and Other Data 
Services to Determine 

- Functional Requirements 

- Designs^ Plans, Methodologies 

- Current Use of Standards 

- Planned Interaction with ADS 

- Role of Standards for ADS Interconnection 

- Suggestions for Standards Development 

- Suggested Standards & Guidelines 



TASK OVERVIEW - A 

0 Organizations and Projects Visited 

- Pilot Atmospheres Data System (GSFC) 

- Earth Resources Pilot (JSC) 

- Oceanic Pilot System (JPL) 

- National Space Science Data Center (GSFC) 

- Environmental Data and Information Service (NOAA) 

- li. S. Geological Survey (DO I) 



TASK OVERVIEW - 5 


0 Determined General ADS Requirements for Standards 

- Interpreted and Integrated Data to Establish 
Common Functional Requirements (To the extent 
Possible without a firm ADS Functional 
Definition) 

- Identified Functional Areas Needing the Support 
Of Standards and Guidelines 

0 Categorized Requirements For Standards According to 
ADS Feature Classification 

0 Identified and Prioritized that Subset of Standards 
Required to Effect the Interconnection of Pilot 
Systems for Data Sharing 



GENERAL FINDINGS - 1 


OBSERVATIONS 

0 De Facto Standards Prevail 

- Use of IBM or IBM look-alike equipment and IBM- 
compatible VENDOR PRODUCTS 

- Use of DEC equipment and products 

- Off-the-Shelf products are cheaper but do not 

SUPPORT THE INTERCONNECTION OF DISSIMILAR SYSTEMS 

0 Trade-Off between Standards and Translations or 
Reformatting 

- Different requirements for short and long term 

- NSSDC SUPPORTS WHATEVER FORMAT IS DESIRED ON 
INPUT OR OUTPUT - THIS "SELLS" WELL^ BUT RE- 
QUIRES SIGNIFICANT TIME AND MONEY 
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GENERAL FINDINGS - 2 
ROLE OF STANDARDS IN ADS 


0 Standards and Guidelines Provide Solutions to the 
Problems Encountered in Interconnecting Dissimilar 
Systems for Data Sharing 

- Varying Terminology 

- Different Data Formats 

- Different Computing Equipment 

- Different Operating Systems 

- Various Data Base Management Systems 

- Different Communications Facilities 

- VI IDE Variety of Data Sets 

- Incompatibility of Catalogs 



GENERAL FINDINGS - 3 


AREAS OF CONCERN 

0 Standards are either inadequate or too 

COMPLICATED 

0 Standards are required only to connect 

DISSIMILAR SYSTEMS 

0 More fruitful to standardize ways of talking 

ABOUT DATA THAN TO STANDARDIZE DATA 

0 Let industry develop standards - utilize 
what's available 

0 Standards work should be practical^ reflect 

THE REAL WORLD 



FUNCTIONAL REQUIREMENTS 
FOR PILOT SYSTEM INTERCONNECTION ' 


0 Requirements for Standards and Guidelines 
Correlated with ADS Feature Classification 

- High level^ top-down model of ADS 

tri 

I 

to 


0 Requirements for Standards and Guidelines 
For Pilot System Interconnection for Data 
Sharing 

- Four of seven columns of ADS classification 

- Correlate with workshop panel subjects 
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C 

Member 

I 

I . 

Applications 

Data 


DaU Definition 
Data Olcllonary 
TimaOellnlllon 
Spatial Definition 
General Vocabulary 
Data Structure and Data Coda 

Data Content 
Data Madia 


DATA FORMATS 
& DESCRIPTIONS 


ADS 



ZL_ 

User-System 

Interface 


Technical 

Service 


User Language 

Applications, Syslem, 
and Network Language 

User Terminal 
User Procedure 


System Locators 

LIstol ADS Users 

Locator ol Data Sets 
and Sources 

Locator ol System 
Services 

System Information 
On-Una 
Oil-Line 

User-to-Usar 
Message Service 


^ CATALOGS 

ySE!^ " DIRECTORIES & 

INTERFACE DICTIONARIES 


Data 

Transfer 

Service 


Data Communications 
Interlaces 

Data Communications 
Protocol 

Physical Layer 

DaU Link Layer 

Network Layer 

Transport Layer 

Session Layer 

Presanutlon Layer 

Application Layer 


ISO/OSI 

MODEL 











REUTIONSHIP BETWEEN FUNCTIONAL, 
TECHNICAL, AND STANDARDS REQUIREMENTS 


ADS REQUIRED REQUIRED 

CAPABILITIES TECHNOLOGY STANDARDS 


List of Data Holdings 

0 Print 

0 Terminology 
0 Data Description 

Remote Access to 
Catalogs 

0 Dial-Up Comm. 

0 DBMS/File Mgmt. 

0 Virtual Terminal Proto. 
0 Catalog Locators 
0 Catalog Structure 
0 Query Language 

Remote Access to Data 

0 High-Speed Comm. 

0 Large Volume Data Mgmt. 

0 Data Formats 
0 Comm. Protocols 
0 Op. Sys. Interface 
0 DBMS Interface 

Distributed Network 

0 Distributed System 
Software (Comm.^ Op. 
Sys., DBMS) 

0 Network Directory 
0 Task Addressing 
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STANDARDS REQUIREMENTS FOR 
APPLICATIONS DATA - 1 


0 ADS Standards for Data Sharing are 
Required in Four General Areas; 

- Data Description 

- Data Formats^ Structures^ and Codes 

- Data Content Representation 

- Data Media 
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STANDARDS REQUIREMENTS FOR 
APPLICATIONS DATA - 2 


DATA DESCRIPTION 

0 Guidelines are required for the description 
OF Data Characteristics 

- Spacecraft and sensors used 

- Sensor characteristics 

- Aspects of reality described by the data 

- Geographical coverage 

- Temporal characteristics of data 

- Form of the data (graphic^ numeric^ textual) 

- Parameters associated with form of data 

- Quality of the data 

- Processing performed on the data 

- Data identification scheme 
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STANDARDS REQUIREMENTS FOR 
APPLICATIONS DATA - 3 


0 General Vocabulary Standards are Required in 
Order to Talk about Data & Data-Related 
Activities 

- Definitions 

- Words 

- Terms 

- Units 

0 Standard Set of Key Elements or Code Names 
For Data Subelements 

0 Spatial Definition Standards for Both Describ- 
ing AND FOR Labeling Data 

- Spatial resolution 

- Spatial location (grids^ 

- Labeling standards 

- Conversion parameters 


COORDINATE SYSTEMS) 



STANDARDS REQUIREMENTS FOR 
APPLICATIONS DATA - 4 


DATA FORMATS/ STRUCTURES. AMD CODES 
0 Two Format Standardization Approaches 

- Standardize the arrangement and representation 

OF DATA. 

- Standardize the mechanism for describing what 

EXISTS WITHIN THE ADS MEMBERSHIP. 

0 Standard Data Interchange Formats are Required for 
Use Between Member-Nodes 

- Standard data descriptors (headers) 

- Standard number representations 

- Standard character codes 

- Standard record structure description 
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STANDARDS REQUIREMENTS FOR 
APPLICATIONS DATA - 5 


0 Standard Terminology and Guidelines are Required 
For the Use of Data Aggregates such as: 

- Strings 

- Arrays 

- Lists 

- Trees 

- Packets 

0 A Methodology for Describing Data Content in a 
Uniform or Standardized Manner is Necessary. 

- Geographic coding and referencing 

- Null^ missing^ or future data 
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STANDARDS REQUIREraiS FOR 
APPLICATIONS DATA - 6 

DATA CONTENT REPRESENTATION 

0 Standard Data Formats are Required to Represent 
Appropriate Categories of Data> such as 

- Image data 

- Graphic data 

- Multidimensional data sets 

- Textual data 

DATA MEDIA 

0 A Family of Standard Media for the Storing and 
Physical Transfer of ADS Data is Needed 

- Magnetic tape 

- Rotating magnetic media 

- Optical STORAGE media 



STANDARDS REQUIREMENTS FOR 
USER-SYSTEM INTERFACE - 1 


Standard Man-Machine Interface Language (s) 

(Command Language^ Menu^ Conversational Inter- 
action^ OR Combination) to 

- Establish interactions with ADS 

- Request help in using ADS 

- Search catalogs of data products and services 

- Request data products and services 

- Request accounting and billing information 

- Report problems 

[User language(s) to do above would require 

TRANSLATION PROTOCOLS FOR 

- Query representation 

- DBMS RESPONSE 

- File structures 

- Data access 

- Catalog structures] 
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STANDARDS REQUIREMENTS FOR 
USER-SYSTEM INTERFACE - 2 


0 Standard Data Manipulation Functions 

- Scaling 

- Summing 

- Combining 

0 Standard Editing Functions 

0 Standard Backup/Recovery Procedures 

0 Guidelines for Terminal Equipment to be 
Supported by ADS 

0 Virtual Terminal Protocol Standard 
0 User Procedure Guidelines 
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STANDARDS REQUIREMENTS FOR 
TECHNICAL SERVICES - 1 


0 Standards are Required for Naming Data 
Sets^ Processes^ and Members within ADS 

- Provide user interface to ADS resources 

- Standard formats for information exchange 

- Accessable by user language 

- "Help" function 



STANDARDS REQUIREMENTS FOR 
TECHNICAL SERVICES - 2 


Standard Format (s) for Listing ADS Members is 
Required that Would List such Items as: 

- Name and address 

- Type of membership 

- Equipment (terminal^ host) 

- Operating system 

- DBMS 

- Traffic capacity 

Summary Level Data Description Standards are 
Required for Data Location 

- Conventions for the existence^ location^ and 

USE OF REDUNDANT DATA ENTITIES 

- Conventions for data base validation 

- Conventions for display of locator responses 

- Standard reference frames (geographical & 
temporal) 



B-26 


STANDARDS REQUIREMENTS FOR 
TECHNICAL SERVICES - 3 


0 Standard Formats are Required for Listing System 
Resources 

- Applications software packages 

. Source 
. Documentation 
. Process residence 

- Computational facilities 

. Location 

. Capabilities/Resources 
. Availability 
. Charges 
. Equipment 

- System services 

0 Standards are Required for Updating^ Adding^ and 
Deleting Information Entities 

- Data 

- Members 

- System resources 
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STANDARDS REQUIREMENTS FOR 
DATA TRANSFER SERVICES - 1 


0 Standards are Required to Facilitate the Transfer 
OF Data Throughout the ADS Network 

- Physical interconnection of dissimilar systems 

- Rules and procedures for transmitting data 

ACROSS THE INTERCONNECTION OF DISSIMILAR 
SYSTEMS 

0 ISO Reference Model for Open System Interconnection 
(IS0/TC97/SC16 N227) Provides a Framework for De- 
fining THESE Standards 
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STANDARDS REQUIREMENTS FOR 
DATA TRANSFER SERVICES - 2 


0 Interconnection Standards are Required for Physical Interface and the 
Methodologies^ Control Procedures^ and Rules which Allow Data Interchange^ 
Some Examples are; 

- Data link characteristics 

. Speed 
. Error rate 

- Transmission characteristics 

. Half or full duplex 
. Synchronous or asynchronous 

- Data orientation 

. Line oriented 
. Character (byte) oriented 
. Bit oriented 
. Packet oriented 

- Data codes 

. ASCII 
. EBCDIC 

- Error control 

. Redundancy 
. Parity 

. Cyclical redundancy check 
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- Terminal characteristics 
. Speeds 
. Codes 

. Coupling (direct^ modern^ or acoustic) 
. Buffering and error control 
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STANDARDS REQUIREMENTS FOR 
DATA TRANSFER SERVICES - 3 

0 Standard Interfaces are Required for the Transfer of Files Among Member 
Nodes of ADS Network. 

- Files include; 

. Data sets 

. Information about data sets 
. General of systems information 
. Messages/queries 
. Applications software 

- Member nodes may include: 

. Individuals 
, Facilities 
. Processes 
. Data 

- Transfer can be: 

. Physical 

. Electronic (many degrees of transparency) 
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STANDARDS REQUIREMENTS FOR 
DATA TRANSFER SERVICES - A 

0 ISO/OSI Model Requires that Standards be Defined 
IN Two Areas 

- Standard ADS services have to be defined 

FOR EACH OF THE MODEL'S LAYERS 

. Functions to be performed in each layer 
. Primitives (request and responses) to be 

PASSED BETWEEN LAYERS 

. Parameter information required to support 

SERVICES 

- Standard peer protocols are required to provide 

NECESSARY PROCEDURES FOR THE FUNCTIONAL UNITS 
WITHIN A SPECIFIC LAYER^ BUT DISTRIBUTED 
THROUGHOUT THE NETWORK, TO INTERACT WITH EACH 
OTHER AND EXCHANGE INFORMATION 
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Node X 


Node Y 


A = Layer Services 
B = Primitives / Parameters 
C = Peer Protocol 

0 Exchange of Primitives and Parameters Support Services Provided by a Layer 
TO its Next Higher Layer 

0 Peer Protocols Handle Interaction Between Units of the Same Layer 
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OS I LAYER CHARACTERISTICS - 1 


PHYSICAL LAYER 


0 Type of Services Provided 

- Physical connection 

- Data unit transmission 

- Fault condition notification 

0 Type of Functions Performed 

- Activation 

- Deactivation 

- Upward multiplexing 

- Fault detection 

0 Primitive / Parameter Examples 

- Connection request 

- Connection indication 

- Fault indication / nature of fault 
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OSI LAYER CHARACTERISTICS - 2 


0 Representative Protocols 

- EIA RS-232-C 

- EIA RS-AA9 

- CCm X.21 



OS I LAYER CHARACTERISTICS - 3 


DATA LINK LAYER 


0 Type of Services Provided 

- Activate^ maintain^ deactivate data links 

- Frame synchronization 

- Error detection and recovery 

0 Type of Functions Performed 

- Data link establishment 

- Data unit transfer 

- Error notification 

- Flow control 

- Downward multiplexing 
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OS I LAYER CHARACTERISTICS - A 

0 Primitive / Parameter Examples 

- Establishment request / address^ facility^ class 

OF SERVICE 

- Reset request 

- Recall request / change connection parameters 

0 Representative Protocols 

- Character-oriented 

. ISO 1745 AND ANSI X3.28 

. IBM BINARY SYNCHRONYMS COMMUNICATIONS 
PROTOCOL (BSC) 

- Bit-oriented 

. ISO HIGH LEVEL DATA-LINK CONTROL (HDLC) 

. ANSI ADVANCED DATA COMMUNICATIONS CONTROL 
PROCEDURE (ADCCP) 

- Others 

. LAP/LAP-B PORTION OF ANSI X.25 
. IBM SYNCHRONOUS DATA LINK CONTROL (SDLC) 
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OS I LAYER CHARACTERISTICS - 5 


NETWORK LAYER 

0 Type of Services Provided 

- Network connection 

- Connection endpoint identification 

- Error notification 

- Sequence control (optimal) 

- Data unit delivery confirmation 

0 Type of Functions Performed 

- Routing and switching 

- Reset 

- Termination 

- Recall 

- Upward multiplexing 
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OSI LAYER CHARACTERISTICS - 6 


- Segmenting and blocking 

- Error detection 

- Error recovery 

- Mapping network addresses with the transport 

ADDRESSES 

- Resource management 

- Relaying (transparent forwarding of data 

UNITS FROM ONE NETWORK ENTITY TO ANOTHER) 

0 Primitive / Parameter Examples 

- Establishment request / address^ facility class 

OF SERVICE 

- Reset request 

- Recall request / network connection parameters 

0 Representative Protocols 

- CCITT X.25 (packet switched) 

- CCITT X.21 (synchronous circuit switched) 

- CCITT .20 (asynchronous public data net) 

- RS-366-A (auto-calling for telephone) 



OS I LAYER CHARACTERISTICS - 7 


TRANSPORT LAYER 


Type of Services Provided 

- Connection establishment 

- Data transfer 

- Flow control 

Type of Functions Performed 

- Selecting appropriate network service 

- Multiplexing transport connections 

- Establishing an optimum data unit size 

- Mapping transport addresses onto the 

NETWORK 

- Detecting errors in received data 

- Bypassing flow control for expedited data 

- Purging data to facilitate recovery 
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OSI LAYER CHARACTERISTICS - 8 


0 Primitive / Parameter Examples 

- Connection request / calling & called 

ADDRESSES^ REQUIRED FACILITIES^ QUALITY 
OF SERVICE 

- Clear indication / network failure 

0 Representative Protocols 

- CCITT RECOMMENDATION S.70 CTELETAX) 

- ARPA TRANSMISSION CONTROL PROTOCOL (TCP 
VERSION A) 
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OSI LAYER CHARACTERISTICS - 9 


SESSION LAYER 


0 Type of Services Provided 

- Session establishment 

- Session management 

- User data exchange 

- Data quarantine (restriction of 

WHICH DATA ARE SENT OR RECEIVED) 

- Interaction management 


f 
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OSI LAYER CHARACTERISTICS - 10 


0 Type of Functions Performed 

- Bind presentation entities into a cooperating 

RELATIONSHIP 

- Enable presentation entities to determine 

UNIQUE VALUES OF OPERATING PARAMETERS 

- Support transfer of unit of data 

- Yields control of data unit to sending 

PRESENTATION ENTITY 

- Provides dialog control used to establish 
2-way simultaneous interaction, 2-way alternate 

INTERACTION, OR 1-WAY INTERACTION 

- Mapping session connections into transport 

CONNECTIONS 

- Flow control 

- Connection recovery 

0 Primitives / Parameters Not Well Defined 

0 Representative Protocols 

- Bell System's version of X.25 (BX.25) which 

DESCRIBES A SESSION LAYER PROTOCOL TO WORK 
WITH Xi25 NETWORK SERVICES. 
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OS I LAYER CHARACTERISTICS - 11 


PRESENTATION LAYER 


0 Type of Services Provided 

- Data TRANSFORMATION: CODE AND CHARACTER SET 

TRANSLATIONS 

- Information formatting: modification of data 

LAYOUT 

- Syntax selection: initial selections and 

SUBSEQUENT MODIFICATION OF THE TRANSFORMATIONS 
AND FORMATS USED 

0 Type of Functions Performed 

- Presentation-service establishment 

- Service initialization 

Image negotiation (determine necessary conversion) 

- Information transformation and formatting 

- Presentation-service release 

0 Primitive / Parameter Example 

- Presentation connection request / code^ format 
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OSI LAYER CHARACTERISTICS - 12 


0 Type of Protocols Under Development 

- Virtual TERMINAL protocol 

. HANDLE A NUMBER OF TERMINAL CLASSES AND PARAMETER 
PROFILES TO ACCOMMODATE DIFFERENT APPLICATIONS 

- Virtual file protocol 

, FORMATTING OF FILE-STORE COMMANDS 
. COMMUNICATION OF FILE INFORMATION 
. CODE CONVERSION 

- Job transfer and manipulation protocol 

. CONTROL OF RECORD STRUCTURES AND RELATED DEVICES 
. COMMAND FORMATTING 
. DATA FORMATTING 
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OSI LAYER CHARACTERISTICS - 13 
APPLICATION LAYER 


0 Type of Services Provided 

- Identification of intended communications partners 

- Agreement on privacy mechanisms 

- Authentication of intended communicants 

- Determination of cost of allocation methodology 

- Determination of adequacy of required resources 

- Determination of the acceptable quality of service 

- Agreement on responsibility for error recovery 

- Information transfer 

0 Type of Functions Performed 

- Initiation of the interconnection 

- Termination of the interconnection 

- Synchronization 

- Commitment of resources 

- Tasking 

- Information transfer 
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OSI LAYER CHARACTERISTICS - lA 


0 Primitives are Undefined 

0 Type of Protocols To Be Developed 

- System management 

. activation/deactivation management 

. MONITORING 
. ERROR CONTROL 
. RECOVERY 

- Applications management 

. authentication 
. access control 
. accounting 

. DEADLOCK RECOVERY 
. COMMITMENT 

- User application 

. REMOTE JOB ENTRY 
. SUBPROCESS SELECTION 
. FILE ACCESS 

. (additional user specific) 



CONCLUSIONS - 1 


Requirements of Pilots for Standards Reflect the 
Functional Priorities and Scope of each Pilot 

- PADS IS CURRENTLY DEALING WITH THE INTERCON- 
NECTION OF DISSIMILAR OPERATING SYSTEMS AND 
DBMSs TO PROVIDE ACCESS TO DISTRIBUTED ATMOS- 
PHERIC DATA AND CATALOGS 

- OPS PRESENT EMPHASIS IS ON THE MANAGEMENT OF 
OCEANIC DATA AND PROVIDING ACCESS TO THESE 
LARGE GEOREFERENCED DATA BASES TO REMOTE USERS 

- ERP IS DEALING PRIMARILY WITH THE CATALOGING 
AND PROVISION OF THE WIDE VARIETY OF DATA 
ASSOCIATED WITH EARTH RESOURCES (LANDSAT 
IMAGERY^ METEOROLOGICAL DATA^ CROP STATISTICS) 
AND THE DEVELOPMENT OF TECHNIQUES FOR MULTI - 
temporal/multi -SENSOR DATA CORRELATION 
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CONCLUSIONS - 2 


CSC / PADS STANDARDS REQUIREMENTS 

0 ADS Standard Data Set Descriptor Language 
0 ADS Transmission Data Format 
0 ADS Data Units Standard 
0 ADS Data Labels Standards 
0 ADS Data Organization Standards 
0 Data Quality Status 

O' Standard for DBMS Call Yielding Attribute Set/ 
Structure Information 

0 ADS Standard Query Language 

- Operator interface 

- Request transmission 

- DBMS INTERFACE 

0 ADS Data Manipulation Language 
0 ADS Data Security Specifications 
0 ADS Interprocessor Command/Status Message Format 
0 Directory Entry Format 
0 Man-Machine Interface 
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CONCLUSIONS - 3 


OCEAN PILOT SYSTEM STANDARDS REQUIREMENTS 


0 Cataloging and Directory Standards 

- Terminology 

0 Communications Protocols 
0 Data Structures 

0 Data Definition 

- Data Element Dictionary 

- DBA Function 

0 Software Transportability 

- TAE, VICAR 

0 ADS System/Network Characteristics 

- Distribution of Data 

- Data to be Shared 

- Standards for User Interface 



CONCLUSIONS - 


EARTH RESOURCES PILOT STANDARDS REQUIREMENTS 


0 Global Data Directory 

- Format and Structure Standards 

0 Access to Catalogs 

- Data Description Standards 

0 Access to Data 

- External Data Format Standards 

- Communication Protocol Standards 

- Standard Interfaces to 

. Operating systems 
. DBMS 
. Users 

0 Standards for Software Transportability 



CONCLUSIONS - 5 


Suggested Priorities for ADS 
Standards Development 

- Terminology 

- Data description 

- Data locations 

- External data format(s) 

- User (command^ query) language 

- Software transportability 

- Dissimilar operating system interfaces 

- Dissimilar DBMS interfaces 
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Paul A. Giragosian 
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OSTA/ADS Data Systems 
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PRESENTATION OUTLINE 


OBJECTIVE 

To Identify and Document Methodologies of the ADS Pilots; 

• Pilot Atmospheres Data System (PADS) 

AT Goddard Space Flight Center (GSFC) 

• Earth Resources Pilot System (ERPS) 

AT Johnson Space Center (JSC) 

• Oceanic Pilot System (OPS) 

AT Jet Propulsion Laboratory (JPL) 

Methodologies MAY Serve as a Basis for the Interconnection of ADS 
Pilots for Data Sharing 



OUTLINE 

(Continued) 


ICTHODOLOGY DEFINITION ; 

Practices, Conventions, Procedures, or Standards which are Utilized 
IN THE Design, Development, and Implementation of the Pilot Systems. 
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OUTLINE 

(Continued) 

Pilot Atmospheres Data System (PADS ) 

• Overview 

• PADS Communication 

- System of Network Application Processors (SNAP) 

- Communication Control Software (COMM) 

- Remote Services Subsystem (RSS) 

• User Interface 

• Catalog Structure 

• Catalog Interface 

• Communication Facility Independence 

• Software Development Methodology 

• Future Methodology Enhancements 
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OUTLINE 


(Continued) 


Earth Resources Pilot System (ERPS) 


• Overview 

• ERP Communications 

• User Interface 

• Research^ Test & Evaluation (RT&E) Data Base 

- RT&E Directory 

- RT&E Catalog Structure 

• Data Definition Structure 

- Data Provisioning 

- Data Handling Techniques 

• Future Methodology Evaluation Programs 



OUTLINE 


(Continued) 

Oceanic Pilot System (OPS) 


• Overview 

• OPS Communication 

• User Interface 

• Data Structure/Definition 

- Standard Format Data Unit (SFDU) 

- Data Handling Methods 

• Catalog Structure 

• Software Development Methodology 

• Future Enhancements 


Conclusions 



PILOT ATMOSPHERES DATA SYSTEM (PADS) 
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PADS COMMUNICATION 


• System of Network Applications Processors (SNAP) 

• Communications Control Software (COMM) 

• Remote Services Subsystem (RSS) 
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INITIAL CONFIGURATION OF SYSTEM OF NETWORKED APPLICATIONS PROCESSORS (SNAP) 


I Visible Infrared Spin Scan Radiometer (VISSR) 

Atmosphere Sounders (VAS) Processor 
PDP - 11/70 
1 RSX - IIM 

\ VAS Data Management System (VASDM) 

/ Integrated Data Base Management System (IDBMS) Processor 
VAX - 11/780 
VAX/VMS ' 

SEED 

Atmospheric and Oceanographic Information Processing System (AOIPS) 

/ PDP - 11/70 
RSX - IID 

\ VAS Data Management System 


Central Communications Processor (CCP) 
PDP - 11/3A 
RSX - IIM 



INITIAL CONFIGURATION OF SYSTEM OF 
NETWORKED APPLICATIONS PROCESSORS (SNAP) 


AOIPS SYSTEM 
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CURRENT PADS/RSS CAPAI^ILITIES 


o Logon/Logoff via Interactive Terminal 

• Establish/Remove User ID and Password 
9 Display Catalog Information 

9 Modify Attribute Values for Local Catalog Entry 

• Allocate New Catalog Entry and Allocate Disk Space 

• Copy a Cataloged Data Set 

• Delete a Catalog Entry and Data Set 

9 Send Message to Other Logged-on User(s) 

• Network Statistics for Network Communication 
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PADS/RSS Provides: 

• Communication Facility Independence 

• User Interface 

• Catalog Interface 
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PADS/RSS COmUNICATION FACILITY IMDEPENDEfICE 


• Packet Communications 

• Virtual Circuit Connection 
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TRANSMISSION TYPES* 


• Request for a Display of Predefined^ Completion or Error Message 

• Request for Data Transmission 

• Application Data Set 

• Temporary Data Set for User Display 

• Remote Service Request 

*Each Transmission Type has a Unique Header Format. 



PADS/RSS COMMUNICATION FUNCTIONS 


• Request Virtual Circuit 

• Respond to Connection Request by Virtual Circuit 
Completion. 

• Send Data Record 

• Receive Data Record 

• Send EOF 

• Disconnect Virtual Circuit 
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PADS/RSS NETWORK 


LAYER 

7 Application 

6 Presentation 

5 Session 

A Transport 

End-to-End 

3 Network Control 

2 Link 

1 Physical 


COmUNICATIONS 


File Transfer 
RSS ■ Catalog Interface 
Message Transfer 

m 

RSS Formatting Service 

RSS Operating System Interface Routines 

COMM 

COFJ^ 

ADCCP/DDCMP 

RS-232C/DMC-11 Coaxial Cable 



C-17 


PADS USER INTERFACE 


- User Interface is Accomplished via a Menu Processor 
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PADS CATALOG STRUCTURE 


3 Level Hierarchical Structure 
First Level 

© OSTA Data Set Directory 

- Test Bed Implementation in June 1981 

- AND UTILIZING VISTA DBMS 

Second Level 

• Pilot Climate Catalog 

- Summary Part Utilizing ORACLE DBMS 

- Text Accessed as an Edit File 

- Implementation Scheduled for July 1981 

Third Level 

• RSS/SNAP Inventories as Defined by VAS DM/TAE Demonstration 



CATALOG INTERFACE DEFINITION 


• Open the Catalog 

• Insert Mew Catalog Entry 

• Delete Catalog Entry 

• Modify Existing Attribute Values 

• Extract Host System Data Set ID 

• Extract User Defined Name and Attribute of Cataloged 
Data Sets 

• Extract Multiple Sets of Catalog Entries Using Search 
Criteria (Name Quantifier) 

• Close Catalog 
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f€THODOLOGY FOR INTERSYSTEM CATALOG I NG OF DATA SET ATTRIBUTES 

• Attribute Mapping and Value Transaction Mechanism 
Needed. 

• PADS Uses "Super Set" Approach. 
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SUPERSET APPROACH 


EACH SYSTEM HAPS ITS OWN 
ATTRIBUTES INTO A MASTER 
EXTERNAL SUPERSET 



SUPERSET 
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RSS SOFTWARE DEVELOPMENT 


• Software Modularity 

• Standardized Language 

• Isolation of Operating System and Catalog 
Management Dependent Routines 
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RSS SOFTWARE MODULARITY 


• Structured Analysis 

• Module Size Limitation 

• Module Prolog Documentation 
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ISOLATION OF OPERATING SYSTEM DEPENDENT ROUTINES 


System Dependent Code is Limited to: 

• Interface to Dissimilar Operating Systems and 
Data Catalogs 

• Encode and Decode Data Transfer Packets 
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FUTURE METHODOLOGY ENHAMCEMEflTS IN THE PADS PROGRAM 


• Extend Present SNAP Configuration to Include Additional Systems 

- VAS Assessment Processor (VAX 11/780 Operating Under TAE) 

- Goddard Modeling & Simulation Facility (AMDAHL A70 V/7B 
Operating Under VM 

- Pilot Climate Data Base Management System (VAX 11/780) 

• Provide Additional User-Oriented SNAP Capabilities 

- Interface to Testbed Central Directory of Data Bases 

- Interface to Other Catalogs/ Inventories (PCDMS) 

- Catalog Search-by-Attribute Query 
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FUTURE METHODOLOGY ENHANCEMENTS IN THE PADS PROGRAM 

(Continued) 

• Utilization of Alternate Netv^ork Communications 
Technology 

- Hyperchannel Local Area Network 

- DECNET 

- Public Packet Switching Network 



EARTH RESOURCES PILOT SYSTEM (ERPS) 
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EARTH RESOURCES PILOT COmUNICATIONS 


Multiple Host: 


Johnson Space 
Center (JSC) 


AS/3000 

3650 COMTEN Communications Processor 
VM/CMS 


Laboratory for 
Applications in 
Remote Sensing 
(LARS) 


IBM 3031 

3670 COMTEN Communications Processor 
VM/CMS 


IBM Bisynchronous Protocol 

Remote Spooling and Communications Subsystem (RSCS) 
Two 9600 Baud Lines Connect the Hosts 
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EARTH RESOURCES DATA APPLICATIONS NETWORK 



JSC TERMINALS LARS TERMINALS 
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EARTH RESOURCES USER INTERFACE 


• CMS Command Language Provides the User with Access 
TO ERDANet Capabilities. 
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RT&E DIRECTORY FOR LANDSAT AND GROUND TRUTH DATA 


• User Access; SUBSET’ 

• User Can Search RT&E Catalog using 32 Different Selection Criteria in 
ANY Combination of Logical Operations. Provisions have been made to 
Accomodate up to 50 Different Search Parameters. 

• User is Supplied with Segment Number and Acquisition Date Information 

NECESSARY FOR CATALOG ACCESS. 
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RISE CATALOG STRUCTURE 


Three Level Hierarchical Structure 

• First Level Provides Access by Data Type and Latitude and 
Longitude 

• Second Level Provides Access to; 

- Meteorlogical Data by Block number and Station number 

- Landsat Data by Segment number^ Acquisition Date and Crop Year 

- Ground Truth Data by Segment number and Acquisition Date 

• Third Level Provides User with Location of Data 
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DATA DEFINITION/STRUCTURE 


• Standard Header Record Formats for 

- Landsat 

- Meteorological Data 
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FUTURE METHODOLOGY EVALUATION PROGRAMS 


• LARS WILL Seek to Standardize on Fortran 77 Programming Language. 

• JSC WILL Continue to Identify and Evaluate Machine Independent 
Languages such as Ada. 

• Explore Wide Bandwidth Communications Methods to Include 
Satellite^ Microwave^ Fiber-Optics. 
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OCEANIC PILOT SYSTEM (OPS) 
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OCEANIC PILOT COMMUNICATIONS 


• VAX/VMS DEC VAX-11/780 Applications Processor 

• RSX-llM DEC PDP-ll/AA Communications Processor 

• PCL-11 Bus 

• DECNET 

• DZ-11 Asynchronous Multiplexer Auto-answer Modem will 
Service Dial-up Terminals at 300 and 1200 bps. 
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OCEANIC CONFIGURATION 



USER TERMINALS 
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USER INTERFACE 


• Menu Driven Interface 

• Command Language Interface 

• Transportable Applications Executive (TAE) 

• Data Base Query Processor 
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m\} PROCESSOR 


• Random Access File of Menu Pages 

• Three Kinds of Menu Subtasks: 

- Input Prompting 

- Display Dynamic System Information 

- Activation and Scheduling of System Functions 
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STANDARD FORMAT DATA UNIT (SFDU) 


• Data will be Stored^ Processed^ and Transmitted 
IN THE Proposed Standard Format Data Unit (SFDU) 
Structure. 


I 
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SFDU STRUCTURE 


Message Data Unit (MDU) 


Message 
Label Group 

Message 
Contents Group 


Primary Label Elements 


Secondary Label Elements 


Text* Elements 


Message; Single MDU 
Batch: Multiple MDUs 

Transmission; Multiple Batches 


Text may Include Numeric 
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BATCH BATA UNIT 


Primary 
Message Data 

■ 

Unit 

Secondary 
Message Data . 
Unit #1 

• 

Secondary 
Message Data . 
Unit #N 


Primary Label 
Secondary Label 
Text 

Primary Label 
Secondary Label 
Text 


Primary Label 
Secondary Label 
Text 



PRIMARY LABEL 


Data Unit Specification 


Character Set Specification* 


Data Unit Contents Classification 


Batch Data Unit Total Length* 


Message Data Unit Total Length 


Start of Message Contents Pointer* 


Optional 




PRIMARY LABEL STRUCTURE CHARACTERISTICS 


• Applications Independent^ Global 

• Physical Characteristics of Data Unit to Include Data 
Unit Length^ Pointers to Start of Message Contents^ 
Character Set 

• Organizational Control 

• Type of Data 

• System Element 

• Member which Created or Modified Data Unit 
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DATA UNIT SPECIFICATION 


8 Bit 


0 

1 

2 

3 

A 

5 

6 

7 


1 

1 

1 






Primary 

Label 

Version 


T 


t 


00 

Defined by Char Set Spec. 

fOl 

Binary 

10 

EBCDIC 

11 

ASCII 


Primary Label Specification 
00 8 Bits 

11 6 Bits (Char. Set Spec. 

Must be Present) 


Data Unit Type 


0 - Message 

1 - Batch (Batch Unit Total Length) 

- 0 Type -1 (No Contents Group) 

- 1 Type 2 (Message Label Group Length Must be Present) 


Primary Label Interpretation 
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CHARACTER SET SPECIFICATION 


Character #1 


Character #2 


ANSI X3.4 - 1977 
X3.41 - 1974 


ANSI Working Paper 
X3L5/80 - 16F 


Defines Specific Character Set 
FOR Message Label Group 
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DATA UNIT CONTENTS 




3 Bytes or 9 Char. 




Control 

Contents 

System 

Secondary 

Authority 

Class 

Class 

Label ID 


Control Authority Defines 
OR Controls Contents of 
Remainder of Data Unit. 

Binary Labels - 6 Bits 

Char. Labels - 2 Char. 


1 

Contents Classification 
Defines Gross Logical 
Association of Application 
Data. 

Binary Labels - 5 Bits 
Char. Labels - 2 Char. 


Secondary Label Identifies 
Secondary Label Structure 
Assoc. WITH System Class. 

Binary Label - 7 Bits 

Char. Label - 3 Char. 


System Class Relates 
Component System 

Binary Label - 6 Bits 
Char. Label - 2 Char. 
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BATCH DATA UNIT TOTAL LENGTH 


<— 4 Bytes or 5 Characters 


Defines the Overall Length of the Complete Batch Data^ 
Starting at the First Bit of this Element and Including 
All of the Remaining Elements Within the Primary and 
Secondary Message Data Units which Comprise the Batch. 

Binary Labels; 4 Octets (32 Bits) Total Number of Octets 
Enclosed Between the First Bit of this Element and the Last 
Bit of the Last MDU within the Batch Data Unit. Char. 
Labels; 5 Char. (30 or 40 Bits) Total Number of Characters 
Between the First Bit of this Element and the Last Bit of 
THE Last MDU Within the Batch Data Unit. 




MESSAGE DATA UNIT TOTAL LENGTH 


« — A Bytes or 5 Characters > 



Defines Length of Message Data Unit from First Bit of This 
Element Including Remaining Labeling and Text Elements, If 
SFDU IS A Batch Data Unit^ This Field Defines Length of Primary 
Message Data Unit. 

Binary Labels: 32 Bits - Contains Subelement Denoting 
Number of 8 Bit Groups from First Bit of Element to Last 
Bit of the MSDU, Char. Labels; 5 Char. (30 or 40 Bits) 

Shall Define Total Number of Characters Between First 
Bit of this Element and the Last Bit of Message Data Unit. 
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START OF MESSAGE CONTENTS POINTER 


i 16 Bits/4 Char. > 


Specifies the Number of Bytes (Octets or Characters) to 
Beginning of Message. 

For Binary Labels, 2 Octets (16 Bits) and Contains 
Binary Quantity which Specifies the Number of Octets 
Between First Bit of this Element and Last Bit of 
Label Structure at Start of Data Unit Contents. 

For Char. Labels 4 Characters Define the Total Number of 
Characters Between First Bit of this Element and Last 
Bit of Label Structure Preceding Start of Data Unit. 
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SECONDARY LABEL STRUCTURE 


Application Dependent 

Defined by Secondary Label ID Field within Primary 
Label 

May Contain Fixed Format Text Elements 

Provides a Wide Variety of Application Keying 
Functions 

Actual Length of any Field is Specified by Secondary 
Label Identifier 

Number of Instances within Any Field is Variable 
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SECONDARY LABEL STRUCTURE 


• Originator Identification Element 

Specific Address of Application Node which First Created Data Unit 

• Modifier Identification Element 

- Identifies Specific Address which Last Modified any Component of 
THE Data 

• Antecedent Process Identification 

Identifies an Audit Trail which Completely Specifies Processes 

WHICH HAVE BEEN APPLIED TO DaTA UnIT SINCE CREATION 

• Data Unit Status Indication Element 

- Used to Record Errors Detected During Data Unit Formation. Also 
Indicates Sequence of Data Segments Contained Within Text and to 
Specify Corrections to Subsequent Secondary Label Fields which 
Form Application Access Keys for Text Data. 
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SECONDARY LABEL STRUCTURE 


• Message Contents Group Counter 

- Defines Number of Standalone Items of Text are Included 
IN THE Message Contents Group. For example^ how many 
Separate Data Packets are Embedded within Message Data 
Unit. 

• Application Keys 

- Provide a Mechanism Whereby Text Data may be Associated 
WITH Application Dependent Reference Keys for Catalog 
Identifications and Access. 
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DATA HANDLING METHODS 


o Magnetic Tape Media 

- 9 Track 

- 800/1600 BPi (Initial Capability) 

- 1000/6250 BPI (Later Capability) 

- Header Record for Each Tape will be Modified 
TO SFDU Format 

• Disk Media 

- 1 Megabyte Limitation 

- SFDU Format 

- Time Duration for Online Residence 



OCEANIC CATALOG INTERFACE 


Online Catalog Access^ Search^ and Display is 
Provided Through Menu Processor. 



OCEANIC CATALOG STRUCTURE 


Two Level Hierarchical Structure 

First Level Contains a Descriptive Overview 
OF THE Data Set 

Second Level. Provides the Data Set Location 
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OCEANIC PILOT CATALOG PRELIHINARY DESIGN 


• Catalog Features 

- Data Set Name 

- Data Set Coverage 

- Data Set Size 

- Geophysical Parameters 

- Sampling Frequency 

- Data Set Residence 



C-59 


SOFTWARE DEVELOPMENT METHODOLOGIES 


• Structured Analysis 

• Top Down Development 

• Modular Design 

• Standard Language 

• Documentation and Coding Standards 



OCEANIC FUTURE ENHANCEMENTS 


Command Language 

Transportable Applications Executive 
Utilization 

Data Base Query Language 

Utilization of High Technology Concepts 

- Digital Optical Disk 

- Data Compression Techniques 



C-61 


CONCLUSION 


• Each ADS Pilot Exhibits 
A Methodology Strength 
In Different Areas 



PADS METHODOLOGY STRENGTHS 


Data Communications 
User Interface 


Data Catalog Structure 
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ERPS METHODOLOGY STRENGTHS 


• Data Definition/Structure 

• Data Catalog Structure 
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OPS METHODOLOGY STRENGTHS 

• Data Format 

• Data Catalog Structure 
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CONCLUSIONS 


a SFDU Concept Provides a Basic Framework for an OSTA/ADS 
Standard Data Format 

- OS I Compatible 

- Applications Oriented 

- Communications Independent 

- Self-Defining 

- Provides Distributed Control 

- Applicable to all Three Pilots 
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OSTA/ADS Data Systems Standards Workshop - i 4 lst of Reference Mat erials 

"The Pilot Atmospheres Data System; Its Methodologies and General Applicability > 
Preliminary Draft, CSC/TM-81/6037, Computer Sciences Corporation, January 1981. 

"The Transportable Applications Executive: A Conceptual Design," Computer Sciences 
Corporation, November 1980. 

"Software Engineering Standards and Practices," Ronald W. Durachka, January 1981. 

"Structured Programming Series. . Volume VII, Addendum: Documentation Standards, 

AD-A016 414, IBM Federal Systems Division, April 1975. 

"Software Acquisition Management Guidebook; Regulations, Specifications and 
Standards," AD-A016 401, MITRE Corporation, October 1975. 

"Programming Language Standards," AD/A-016 771, IBM Corporation, March 1975. 

"Telemetry Computation Branch Quality Assurance Procedures Programming and 
Documentation Standards," CSC/T^^-76/6115, Computer Sciences Corporation, May 1976. 

"Standards Guide for Space and Earth Sciences Computer Software," X-601-72-7 Preprint, 
Goddard Space Flight Center, January 1972. 

"Federal Computer Network Protocol Standards Program; An Overview," Institute for 
Computer Sciences and Technology, National Bureau of Standards. 

"Federal Information Processing Standards Publications (FIPS PUBS) ," Revision, 
Institute for Computer Sciences and Technology, National Bureau of Standards, 

February 1980. 

"^j-chitectural Considerations for Federal Database Standards, Seymour Jeffery, 

Dennis Fife, Donald Deutsch and Gary Sockut, Systems and Software Division, National 
Bureau of Standards, December 1978. 

"DBMS Standards: Current Status and Future Directions," Donald R. Deutsch and 

Eric K. Clemons. 

"Conversion of Federal ADP Systems; A Tutorial," Joseph Colllca, Mark Skall, 

Gloria Bolotsky, Institute for Computer Sciences and Technology, National Bureau of 
Standards, August 1980. 

"Features of Network Interptocess Communication Protocols," Draft Report, 
ICST/HLNP-80-12, Systems and Network Architecture Division, National Bureau of 
Standards, September 1980. 

"Formal Description Techniques for Network Protocols," Draft Report, ICST/HLNP-80-3 , 
Systems and Network Architecture Division, National Bureau of Standards, June 1980. 

"Features of the File Transfer Protocol (FIP) and the Data Presentation Protocol 
(DPP)," Draft Report, ICST/HLNP-80-6, Systems and Network Architecture Division, 
National Bureau of Standards, September 1980. 


"Features of Internetwork Protocol," Draft Report, ICST/HLNP-80-8, Systems and 
Network Architecture Division, National Bureau of Standards, July 1980. 



"Service Spec^ication of the File Transfer Protocol (FTP) and the Data Presentation 
Protocol (DPP), Draft Report, ICST/HLNP-80-9, Systems and Network Architecture 
Division, National Bureau of Standards, October 1980. 


Service Specification of an Internetwork Protocol," Draft Report, lCST/HLNP-80-11 
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"User Computer Compatible Tape (CCT) Format Family Requirements," CCB-CCT-OOOIA, 

October 16, 1978. 

"Landsat-D User CCT Tape Format," FOR-LSD-0001 A, August 28, 1979. 

"The CCT Family of Tape Formats ," ,CCB-CCT-0002 A, August 28, 1979. 

"EDIS Data Dictionary System, Version I User's Guide." Environmental Data and 
Information Service, NOAA, June 1980. , 

"Aerospace Data Systems Standards," X-560-63-Z, Goddard Space Flight Center, 

January, 1963. 

"NASA End-to-End Data System (NEEDS) Guidelines for Data Communications Standards; 
Packet Telemetry," Needs Modular Data Transport System Team, January 30, 1981. 

"Applications Data Service (ADS) Study Report," R.F. desJardins, NASA/Goddard 
Space Flight Center, May 1981. 

"OSTA Data Systems Planning Workshop Report," R.F. desJardins, NASA/Goddard 
Space Flight Center, May 1981. 

"Survey of Federal, National, and International Standards Applicable to the 
NASA Applications Data Service," T. Kuch and R. Sakamoto, NASA Contract Report 
166675, NASA, March 1981. 
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"An Automated Registration System," N.Y. Chu and R.L. Nugent, Lockheed, December 1980. 

"A Case Study in Data Management in a Research and Operational Composite Environment, 
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"Handbook for the Preparation of Interface Control Documentation," Thomas Chen, 
MITRE Technical Report MTR-4827, MITRE, September 1980. 

"Alternative System Architectures for Data Catalogs in a Distributed Data 
Base Environment," Terry Kuch, May 7, 1981. 

"Common Operating System Command Language," CODASYL, Journal of Develonment 
September 1980. ’ 

"Operating System Command and Response Language - Design Criteria," ANSI 
September 1980. 

"Operating System Command and Response Language - Draft Language Specification " 
ANSI, April 1981. 

"Draft Vocabulary for Use by X3H1," S.J. Mellor, University of California 
February 2, 1981. 

"Virtual Terminal Feature Analysis," Draft Report, ICST/HLNP-81-3, Systems And 
Network Architecture Division, National Bureau of Standards, March 1981. 

Specification And Analysis of Local Area Network Architecture Based on the ISO 
Reference Model," Draft Report, ICST/LANP-81-1, Systems & Network Architecture 
Divisxon, National Bureau of Standards, April 1981. 

Service Specification of a Network Interprocess Communication Protocol," 

Draft Report, ICST/HLNP-80-15, Systems & Network Architecture Division, 

National Bureau of Standards, October 1980. 
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APPENDIX E 


UNPUBLISHED PREWORKSHOP DOCUMENTATION 




Reply 


National Aeronautics and 
Space Administration 

Goddard Space Flight Center 
Greenbelt. Maryland 
20771 




934 

TO: Distribution 

FROM: 934 /Coordinator OSTA/ADS Data Systems Standards Workshop 

SUBJECT: Office of Space and Terrestrial Applications /Applications 

Data Service (OSTA/ADS) Data Systems Standards Workshop 


You are cordially invited to attend the Office of Space and Terrestrial 
Applications/Applications Data Service (OSTA/ADS) Data Systems Standards 
Workshop to be held at Goddard Space Flight Center in Greenbelt, Maryland 
May 27-29, 1981. During the meeting, the work of the ADS Standards 
contractor MITRE will be reviewed and guidance and suggestions will be 
given for consideration in preparing the Preliminary OSTA/ADS Standards 
and Guidelines, planned for August publication. Related information and 
plans will also be shared. 

The planned agenda for the workshop is enclosed. Your attention is called 
to the panel sessions Thursday afternoon. The purpose of the panels is to 
provide in-depth discussion on high priority subjects among persons with 
expertise in these areas. Five topics have been identified which may be 
superseded by issues or items of greater Importance that are identified 
during the workshop. 

The evening dinner session scheduled for Wednesday, May 27th, will feature 
James Burrows, Director of the Institute for Computer Science & Technology 
of the National Bureau of Standards. He will discuss the NBS Data Systems 
Standards Program. 

The workshop is scheduled to begin at- 9:00 a.m. Wednesday, May 27 in Building 
26, Room 205, with registration beginning at 8:30. A map of the Center is 
enclosed for your convenience. Your name will be given to the Gatehouse for 
a security pass to be picked up when you enter the facility. During the 
conference, messages may be left for attendees at (301)344—5831. 

The conference room is equipped with a viewgraph machine and screen. If you 
are a speaker and require any additional audio-visual equipment, please inform 
us as soon as possible. Presenters are asked to bring original artwork or 
good xerox copies of their viewgraph material in order to simplify art 
reproduction for the conference report. 
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There are no registration fees as such associated with the workshop. There 
will, however, be a fee of approximately $6.00 for refreshments during the 
conference and at the Thursday evening panel working session. The Wednesday 
evening dinner session will be held at a local resturant. Dinner tickets 
may be purchased at registration for approximately $10.00. 

The Systems and Applied Sciences Corporation (SASC) is assisting the 
sponsor in coordinating the Workshop. If you need help with transportation 
or reservations, or have any general logistic questions, please direct them 
to Ms. Linda Mason, SASC, (301)699-5400 or (800)638-0925. Questions 
regarding the technical program should be directed to Barbara Walton, 

FTS 344-9413. 

Included with this letter is a list of hotels/motels in the Greenbelt area. 
Those individuals coming from out of town should make reservations at the 
hotel of their choice as soon as possible. YoU are also asked to fill out 
the enclosed form indicating your Intention to attend and return it to the 
address below. 


Ms. Linda Mason 
Conference Management 

Systems And Applied Sciences Corporation 
6811 Kenilworth Avenue 
Riverdale, Maryland 20840 


Barbara Walton 
Enclosures 
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Reply to Attn of. 


National Aeronautics and 
Space Administration 

Goddard Space Flight Center 

Greenbelt, Maryland 
•20771 


IVI/NSA 


934. 

TO: Respondents 

FROM: Coordinator, OSTA/ADS Data Systems Standards Workshop 

SUBJECT: Pre-Workshop Documentation 

This pre-workshop mailing is being made to aid participants in preparing for 
the Office of Space and Terrestrial Applications/Applications Data Service 
Data Systems Standards Workshop to be held at Goddard Space Flight Center 
May 27-29, 1981. The theme of the workshop is "Standards Needed to Inter- 
connect ADS Pilots for Data Sharing." The following documentation is 
attached: 


1. OSTA/ADS Data Systems Standards Workshop - Instructions to Panels 

2. OSTA/ADS Data Systems Standards Workshop - List of Reference 

Materials 

3. Abstract and goal of each MITRE Workshop session 

4. Excerpts from "Applications Data Service (ADS) Study Report" 

5. Excerpts from "OSTA Data Systems Planning Workshop Report" 

6. Excerpts from "Survey of Federal, National, and International 

Standards Applicable to the NASA Applications Data Service" 

7. "Data-Processing - Open Systems Interconnection - Basic Reference 
Model" 

8. "Guidelines for the Organization and Representation of Data Elements 
for Data Interchange" 

9. "Overview and Status of the ISO/ANSI Reference Model of Open Systems 
Interconnection" 

10. "Multimission End-to-End Information System (EEIS) 'Standard Format 
Data Unit' Development Guidelines and Standards," Preliminary 
Review Draft 

In addition, a "library" of reference materials for use by the panels is being 
gathered. A list of the references which have been gathered to date is attached. 
Please bring any additional references to the workshop or mail to 

Barbara A. Walton 
Code 934 

Goddard Space Flight Center 
Greenbelt, Maryland 20771 

in time for arrival by May 26, 1981. 

Please review the enclosed material prior to the meeting. Items 1 and 3, 
sections 6 and 10 of 4, section 13 of 5, and section 2 of 6 are especially 
critical for your participation. Additionally, the executive summaries of 
4 and 5 provide excellent background material if you are unfamiliar with ADS. 

The remaining material is more specific to individual panel concerns. 
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Page 2 


If you have any general logistic questions, please contact Linda Mason, 
Systems and Applied Sciences C -rporation, 301-699-6279. Questions regarding 
the technical program should be directed to Barbara Walton at FTS 344-9413. 


(fe PH M 

Barbara Walton 
Enclosures 


E-4 



OSTA/ADS Data Systems Standards Workshop - Instructions to Panels 


The theme of this workshop, being held May 21 — 29 ^ 1981* is "Standards Needed to 
Interconnect ADS Pilots for Data Sharing." The materials you have been sent are 
intended to help in your preparation for the workshop. Please try to read at least 
the sections mentioned in the cover memo and bring them with you to the workshop. 
General instructions for panels during the workshop follow. 

1. Critique the MITRE representation of pilot methodologies for accuracy 
and completeness. 

2. Identify the requirements for standards and guidelines needed in your 
panel's area to interconnect the ADS pilots for data sharing. Describe 
these requirements as separate elements and 'establish an orderly method 
for identifying and grouping the elements. (This identification method is 
to be used in all the following steps to track, trace, or label related 
information) . 

3. Make a preliminary assessment of the adequacy of currently Identified pilot 
methodologies and external standards in meeting these requirements. 

4. Identify any other methodologies you are aware of which may contribute to 
the solution to your panel's aspect of the problem. 

5. Make recommendations for future work, providing descriptions and estimate 
of effort where possible. 

6. Provide the panel's consensus on the need for a continuing working group 
in this area and suggest membership thereof. 

Each panel will be asked to draft a short report summarizing its results. Secretarial 
support will be provided to facilitate this. More specific information for each panel 
area and additional Issues to be addressed follow. 
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Standards Needed to Interconnect ADS Pilots for Data Sharing 


Panel A - Catalogues, Directories, and Dictionaries 


Chairman: Jose Urena, JPL - FTS 792-3428 


Multiple definitions for the above terms are in current use within OSTA/ADS. 
Consideration needs to be made of the functional layers of information about data 
and the responsibilities for producing that information within the OSTA. These 
layers should be refined and terminology to reference each recommended in order 
to facilitate future communication. 
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Standards Needed to Interconnect ADS Pilots for Data Sharing 


Panel B - User Interfaces 


Chairman: Jim Brown, JPL - FTS 792-5109 


Some of the key elements of this area are: 

(1) Dial-up procedures 

(2) Terminals (minimum, desirable, extended capability) 

(3) Common capabilities 

(4) Language Interfaces (query, command, menu) 

(5) Display capabilities 
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Standards Needed to Interconnect ADS Pilots for Data Sharing 


Panel C - Use of ISO Open Systems Interconnection - Basic Reference Model 


Chairman: Ed Greene, GSFC t 344-8685 


This panel will address the question of which layer (s) should be used for pilot 
interconnection, which protocol to use and what interfaces between higher layers 
are needed. More specifically, the panel is asked to come to consensus as to what 
each layer means within OSTA/ADS. Use of X.25, TELENET, DECNET and PADS RSS should 
be examined for potential impact. 
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Standards Needed to Interconnect ADS Pilots for Data Sharing 
Panel D - Data Formats and Descriptions 

Chairman: Ed Greenberg, JPL - FTS 792-3387 

Some of the key elements of this area are: 

(1) Structure/organization of data sets 

(2) Header content and format 

(3) Character codes 

(4) Data codes 

Please note that data description as used by this panel is information about data 
required for processing data, vdiereas catalogs contain information required to locate 
data and request access. 
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Appendix F 


OSTA/ADS Data Systems Standards Workshop - List of Attendees 


Portia W. Bachman 
Goddard Space Flight Center 
Code 934 

Greenbelt, MD 20771 
(301) 344-9415 

Earl Beard 

Goddard Space Flight Center 
Code 565 

Greenbelt, MD 20771 
(301) 344-5623 

William Benton 
Lockheed 

. 1830 NASA Road 1 
Houston, TX 77058 

Richard L. Berman 
Computer Sciences Corp. 

8728 Colesville Road 
Silver Spring, MD 20910 
(301) 589-1545 x228 or x770 

Manju Bewtra 
Computer Sciences Corp. 

8728 Colesville Road 
Silver Spring, MD 20910 
(301) 589-1545 x771 

Joseph Bishop 
NASA HQ, Code TS 
600 Independence Ave. , SW 
Washington, DC 20546 
(202) 755-2430 

William Bisignani 
MITRE Corp. 

1820 Dolley Madison Blvd. 
McLean, VA 22102 
(703) 827-6806 

Albert W. Bowers 
MITRE Corporation 
1820 Dolley Madison Blvd. 
McLean, VA 22102 
(703) 827-6871 


Gary Brammer 
LARS 

Purdue University 
1220 Potter Drive 
West Lafayette, IN 47906 
(317) 749-2052 

James W. Brown 

Jet Propulsion Laboratory 

Code 125/128 

4800 Oak Grove Drive 

Pasadena, CA 91109 

(213) 354-5109 or FTS 792-5109 

Thomas Bums 

MITRE Corporation 

1820 Dolley Madison Blvd. 

McLean, VA 22102 
(703) 827-6886 

James Burrows 

National Bureau of Standards 
Room A200, Building 101 
Washington, DC 20234 
(202) 921-3151 

Paul Clemens 
MITRE Corporation 

1820 Dolley Madison Blvd. , Rm. W665 
McLean, VA 22102 
(703) 827-6659 

Christopher J. Daly 
Goddard Space Flight Center 
Code 565.1 

Greenbelt, MD 20771 
(301) 344-6605 

Richard desJardins 

Computer Technology Associates 

1501 Wilson Blvd. 

Arlington, VA 22209 
(703) 841-0787 

Ai C . Fang 
NASA HQ, Code ECD-4 
600 Independence Ave., SW 
Washington, DC 20546 
(202) 755-8573 
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Dennis Fife 

National Bureau of Standards 
Room A257, Building 225 
Washington, DC 20234 
(202) 921-3491 

David Freeman 
LARS 

Purdue University 
1220 Potter Drive 
West Lafayette, IN 47906 

J. Patrick Gary 

Goddard Space Flight Center 

Code 934 

Greenbelt, MD 20771 
(301) 344-6079 

Paul Giragosian 
MITRE Corporation 
1820 Dolley Madison Blvd. 
McLean, VA 22102 
(703) 827-6924 

Ronald C. Glaser 

Computer Sciences Corporation 

9504 Dragon Claw 

Columbia, MD 21046 

(301) 596-3946 

Alan Goldfine 

National Bureau of Standards 
Washington, DC 20234 

Edward Greenberg 

Jet Propulsion Laboratory 

MS 233-208 

4800 Oak Grove Drive 

Pasadena, CA 91109 

(213) 354-3387 

Edward Greene 

Goddard Space Flight Center 
Code 503 

Greenbelt, MD 20771 
(301) 344-8685 

Edgar M. Greville 
Computer Sciences Corporation 
8728 Colesville Road 
Silver Spring, MD 20910 
(301) 589-1545 x696 


Steve Haight 
ORI, Inc. 

1400 Spring Street 
Silver Spring, MD 20910 
(301) 588-6180 x265 

Larry Herath 

Goddard Space Flight Center 
Code 931.2 

Greenbelt, MD 20771 
(301) 344-9521 

Adrian Hooke 

Jet Propulsion Laboratory 
4800 Oak Grove Drive 
Pasadena, CA 91109 
(213) 354-3063 

David Howell 

Goddard Space Flight Center 
Code 933.1 

Greenbelt, MD 20771 
(301) 344-9041 

John Johnson 

Jet Propulsion Laboratory 
Code 79-6 

4800 Oak Grove Drive 
Pasadena, CA 91109 
FTS 792-2143 

Leon Jordan 

Computer Sciences Corporation 
8728 Colesville Road 
Silver Spring, MD 20910 

John Kiebler 
NASA HQ, Code ECD-4 
600 Independence Ave. , SW 
Washington, DC 20546 
(202) 755-8573 

Stan Klein 
ORI, Inc. 

1400 Spring Street 
Silver Spring, MD 20910 

Gerald M. Knaup 

Goddard Space Flight Center 

Code 934 

Greenbelt, MD 20771 
(301) 344-6034 
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Lou Kramer • 

LARS 

Purdue University 
1220 Potter Drive 
West Lafayette, IN 47906 

Terry Kuch 

MITRE Corporation 

1820 Dolley Madison Blvd. , Rm. W27 

McLean, VA 22102 

(703) 827-7124 

Robert R. Lovell 
NASA HQ, Code EC-4 
600 Independence Avenue, SW 
Washington, DC 20546 

Merv MacMedan ^ 

Jet Propulsion Laboratory 
Code 233-208 
4800 Oak Grove Drive 
Pasadena, CA 91109 
FTS 792-7004 or 5793 

James Moulton 

National Bureau of Standards 
Room B219, Building 225 
Washington, DC 20234 
(202) 921-2601 

Lawrence V. Novak 
Goddard Space Flight Center 
Code 931 

Greenbelt, MD 20771 
(301) 344-9538 

William Poland 

Goddard Space Flight Center 

Code 730.4 

Greenbelt, MD 20771 
(301) 344-8592 

Richard D. Sakamoto 

MITRE Corporation 

1820 Dolley Madison Blvd. 

Room W657 
McLean, VA 22102 
(703) 827-7022 

Roy G. Saltman 
National Bureau of Standards 
Building 225 
Washington, DC 20234 
(202) 921-3491 


Ed Schlosser 
Lockheed 
1830 NASA Road 
Houston, TX 77058 

William Shaffer 
NASA HQ, Code ECD-4 
600 Independence Avenue, SW 
Washington, DC 20546 

A1 Skopetz 

Goddard Space Flight Center 
Code 730.4 

Greenbelt, MD 20771 
(301) 344-8593 

Peter M. Smith 

Goddard Space Flight Center 

Code 931.2 

Greenbelt, MD 20771 
(301) 344-9489 

Robert R. Stephens 
NASA HQ, Code TS 
600 Independence Avenue, sW 
Washington, DC 20546 
(202) 755-2430 

Sam Steppel 

Computer Sciences Corporation 
8728 Colesville Road 
Silver Spring, MD 20910 
(301) 589-1545 x674 

Ellen G. Stolarlk 
OAO Corporation 
5050 Powder Mill Road 
Beltsville, MD 20705 
(301) 937-3090 

Frank Stone 
OAO Corporation 
5050 Powder Mill Road 
Beltsville, MD 20705 

David Stowell 
OAO Corporation 
5050 Powder Mill Road 
Beltsville, MD 20705 

Valerie L. Thomas 
Goddard Space Flight Center 
Code 563 

Greenbelt, MD 20771 
(301) 344-5252 


F-3 



Jose Urena 

Jet Propulsion Laboratory 
Code 138-308 
4800 Oak Grove Drive 
Pasadena, CA 91109 
FTS 792-3428 

Anthony Villasenor 
NASA HQ, Code ECD-4 
600 Independence Avenue, SW 
Washington, DC 20546 
(202) 755-8573 

Barbara A. Walton 
Goddard Space Flight Center 
Code 934 

Greenbelt, MD 20771 
(301) 344-9413 

Noreen Welch 
ORI , Inc . 

1400 Spring Street 
Silver Spring, MD 20910 


Jim Wilkinson 
Lockheed 
1830 NASA Road 
Houston, TX 77058 

Fred Wulff 
NASA HQ, Code T 
600 Independence Avenue, SW 
Washington, DC 20546 
(202) 755-2430 

Frank Yap 

Computer Sciences Corporation 
8728 Colesville Road 
Silver Spring, MD 20910 
(301) 589-1545 x773 

Phil Yu 

Goddard Space Flight Center 
Code 934 

Greenbelt, MD 20771 
(301) 344-9414 


F-4 






BIBLIOGRAPHIC DATA SHEET 


1. Report No. 

NASA CP-2196 


2. Government Accession No. 


4. Title and Subtitle 

OFFICE OF SPACE AND TERRESTRIAL APPLICATIONS 
(OSTA) /APPLICATIONS DATA SERVICE (ADS) DATA 
SYSTEMS STANDARDS 


7. Author(s) 

Barbara A. Walton, editor 


9. Performing Organization Name and Address 
Goddard Space Flight Center 
Greenbelt, MD 20771 


3. Recipient's Catalog No. 


5. Report Date 

December 1981 


6. P^g^^rming Organization Code 


8. Performing Organization Report No. 


10. Work Unit No. 


1 1 . Contract or Grant No. 


12. Sponsoring Agency Name and Address 
National Aeronautics and Space Administration 
Washington, DC 20546 


13. Type of Report and Period Covered 


Conference Publication 


14. Sponsoring Agency Code 



16. Abstract 

This volume contains the proceedings of the Office of Space and Terrestrial 
Applications (OSTA) /Applications Data Service (ADS) Data Systems Standards 
Workshop, held May 27-29, 1981 at Goddard Space Flight Center in Greenbelt, 
Maryland. The purpose of the workshop was to identify standards needed 
to interconnect ADS pilots for data sharing, to assess current pilot 
methodologies, and to make recommendations for future work. The theme of 
the panel groups was "Standards Needed to Interconnect ADS Pilots for 
Data Sharing." The panel topics were; catalogs, directories, and 
dictionaries; user interfaces; use of ISO open systems interconnection - 
basic reference model; and data formats and descriptions. This docimient 
contains reports from the panels, summaries of the talks and discussions, 
and view-graph presentation material. 


17. Key Words (Selected by Author(s)) 

Applications Data Service 
Data Systems Standards 
Guidelines 

Data Sharing Network 


18. Distribution Statement 


Unlimited - Unclassified 


Subject Category 14 


19. Security Classif. (of this report) 
Unclassified 

1 

20. Security Classif. (of this page) 

Unclassified 

21. No. of Pages 
276 

22. Price* 
A13 

*For sale by the National Technical Information Service, Springfield, Virginia 22161. 


GSFC 25-44 (10/77) 


*U.S. GOVERNMENT PRINTING OFFICE: 1981 539 - 007/26 1-3 























National Aeronautics and 
Space Administration 


SPECIAL FOURTH CLASS MAIL 
BOOK 


Washington, D.C. 
20546 


Official Business 

Penalty for Private Use, $300 


Postage and Fees Paid 
National Aeronautics and 
Space Administration 
NASA-451 





POSTMASTER: 


If Undeliverable (Section 158 
Postal Manual) Do Not Return 


